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Thank  you  for  that  warm  introduction.  (Bill  Collier,  Chairman)  And 
thank  you  for  the  invitation  to  speak  here  today. 

I  am  particularly  struck  by  your  theme:  “Meeting  the  technology 
needs  of  the  warfighter  in  the  year  2000  and  beyond”  because  clearly  this  is 
the  mission  of  my  own  organization.  And  looking  to  how  we  meet  future 
warfighting  needs  with  technology  is  certainly  critical  for  us. 

Environment 


You  know,  meetings  such  as  this  provide  us  an  opportunity  to  look 
to  the  future  and  I  want  to  do  that  with  you.  Charles  Kettering  said  we 
should  all  be  concerned  about  the  future  because  we  will  have  to  spend  the 
rest  of  our  lives  there.  What  the  future  has  in  stock  for  us  will  depend 
largely  on  what  we  place  in  stock  for  the  future.  The  worst  thing  about  the 
future  is  that  it  gets  here  faster  than  it  used  to. 

In  1789,  George  Washington  took  eight  days  to  travel  the  distance 
from  his  home  in  Mount  Vernon  to  the  scene  of  his  inauguration  in  New 
York  City.  The  eight  days  in  itself  is  not  significant.  The  important  fact  is 
that  this  is  the  same  amount  of  time  that  it  would  have  taken  to  travel  that 
distance  1000  years  before.  There  was  no  real  progress  in  transportation  in 
20  centuries — since  Moses  or  Nebuchadnezzar.  Julius  Caesar  could  have 
stepped  from  the  first  to  the  19th  century  more  easily  than  Ben  Franklin  into 
the  next.  Now,  for  the  first  time  in  history,  no  man  dies  in  the  same  epoch 
in  which  he  is  bom. 

Understanding  the  future  has  always  been  central  to  warfighting 
strategy.  Soviet  Major  General  Sergei  Kozlov  said  that  “the  most  significant 
task  of  military  science  has  always  been  defining  the  character  of  future 


If  we  think  back  to  when  the  Victorian  era  came  to  a  close  and  the 
20th  Century  came  into  view,  would  our  predecessors  have  foreseen  that  in 
less  than  a  single  generation  the  greatest  war  in  history  would  break  out? 
Would  they  have  they  anticipated  that  in  less  than  a  single  short  career,  they 
would  see  the  emergence  of  the  airplane,  the  tank,  the  submarine  and  the 
wireless  radio  —  systems  that  would  transform  forever  the  field  of  human 
conflict?  Or  would  they  have  extolled  the  virtues  of  horse  cavalry, 
observation  balloons  and  the  bayonet? 

Much  of  the  tragedy  of  the  First  World  War  stemmed  from  the 
inability  of  the  military  leaders  of  the  day  to  grasp  the  implications  of 
change.  Their  failure  doomed  an  entire  generation  and  led  directly  to  a 
second,  even  more  destructive  global  war. 

It  is  our  responsibility,  that  of  each  and  every  one  of  us,  to  do  all  in 
our  power  to  see  that  we  are  ready  for  tomorrow,  that  we  never,  ever, 
allow  complacency  to  take  hold.  In  a  very  real  sense  that  is  why  you  are 
here.  And  make  no  mistake:  the  stakes  you  are  playing  for  remain  very  high 
indeed. 

What  will  the  future  look  like?  Almost  certainly  we  will  not  face  a 
hostile  superpower  in  the  near  term,  but  the  world  will  remain  a  dangerous 
place.  There  will  be  many  who  do  not  share  our  values,  many  who  will 
challenge  our  interests,  and  many  who  will  threaten  our  friends  and  allies. 
Some  of  these  threats  will  look  familiar.  The  nation-state,  after  all,  will  still 
be  with  us  for  a  long  time  to  come,  and  so  will  armies,  navies  and  air 
forces  much  as  we  know  them  today. 

But  the  21st  Century  will  also  see  the  non-state  actor  come  of  age. 
Fanned  by  the  ancient  flames  of  ethnic,  religious,  cultural,  and  economic 
rivalry,  many  groups  will  challenge  us  at  home  and  abroad.  However,  unlike 
past  eras,  terrorist  groups  and  other  non-state  actors  will  have  access  to 
state-of-the-art  technology.  They  will  have  secure  communications  and 
access  to  global  positioning  satellites,  highly  advanced  computer  technology 
and,  perhaps  most  frightening  of  all,  weapons  of  mass  destruction.  The 
proliferation  of  advanced  technology  with  military  applications  has  been  so 
rapid  and  so  pervasive  that  our  enemies  in  the  next  century  will  have 
capabilities  they  could  only  dream  about  in  this  one. 


And  whether  those  enemies  come  in  the  form  of  nation-states,  or 
rogue  organizations  pursuing  their  own  agendas,  they  will  have  learned  to 
challenge  us  asymmetrically  —  not  where  we  are  strong,  but  where  they 
think  we  are  vulnerable. 

Thus,  preparing  to  respond  to  the  full  range  of  asymmetric  threats 
should  increasingly  occupy  our  interest,  our  time,  and  our  energy.  Now  is 
the  time  we  should  be  doing  that,  now  when  we  have  a  window  of 
opportunity,  when  we  don't  have  to  worry  about  a  strategic  rival  that  could 
threaten  our  existence  as  a  nation. 

Our  best  thinking  about  how  we  should  fight  in  the  21st  Century  is 
found  in  Joint  Vision  2010,  our  conceptual  template  for  future  joint 
operations.  Most  of  you  are  probably  familiar  with  JV2010,  at  least  in  its 
broad  outlines.  The  four  pillars  of  Joint  Vision  2010  are  its  key  operational 
concepts:  Dominant  Maneuver,  Precision  Engagement,  Focused  Logistics 
and  Full  Dimensional  Protection,  and  two  "enablers"  —  technological 
innovation  and  information  superiority.  Each  of  these  are  very  powerful 
individually,  but  they  are  not  ends  in  themselves. 

The  ultimate  goal  for  joint  warfighting  in  the  future  is  decisive 
operations:  the  ability  to  win  quickly  and  overwhelmingly  across  the  entire 
range  of  operations,  or  in  other  words,  Full  Spectrum  Dominance.  We 
want  our  men  and  women  to  be  the  masters  of  any  situation.  In  combat, 
we  do  not  want  a  fair  fight — we  want  capabilities  that  will  give  us  a  decisive 
advantage. 

Implications 

The  implications  of  Joint  Vision  2010  should  be  clear  for  us  in  the 
acquisition  community.  There  are  number  of  critical  enablers  that  are 
absolutely  essential  to  our  ability  to  shape  the  international  security 
environment  and  respond  to  the  full  spectrum  of  crises.  Two  of  those  are  of 
special  importance  to  us  here  today — harnessing  advanced,  complex 
technologies  to  achieve  the  desired  Revolution  in  Military  Affairs.  And 
reengineering  our  acquisition  process  to  meet  the  affordability  challenge 
through  a  Revolution  in  Business  Affairs. 

Technology  will  need  to  be  developed,  tested,  and  sustained  that  can 
profoundly  affect  the  warrior  and  leader  who  will  execute  2010  missions. 
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Exploiting  the  Revolution  in  Military  Affairs  involves  more  than  the 
acquisition  of  new  military  systems.  It  means  leaping  ahead 
technologically — not  creeping  ahead.  It  means  harnessing  these  new 
technologies  to  give  U.S.  forces  greater  military  capabilities  through  advanced 
concepts,  doctrine,  and  organizations  so  they  can  dominate  any  future 
battlefield.  And  it  means  more  than  ever  dealing  with  the  complexity  of  a 
systems  of  systems  approach. 

The  U.S.  military’s  modernization  effort  is  directly  linked  to  the 
broader  challenge  of  a  Revolution  in  Business  Affairs.  Efforts  to  reengineer 
the  Department’s  infrastructure  and  business  practices  must  parallel  the  work 
being  done  to  exploit  the  Revolution  in  Military  Affairs  if  the  nation  is  to 
afford  both  adequate  investment  in  preparations  for  the  future,  especially  a 
more  robust  modernization  program,  and  capabilities  sufficient  to  support  an 
ambitious  shaping  and  responding  strategy  through  2015. 

I  see  our  challenge  as  three-fold: 

1.  Conceiving,  designing,  developing,  testing,  producing,  fielding,  and 
supporting  complex  technologies  that  enable  our  new  warfighting 
concepts. 

2.  Doing  this  in  substantially  less  time.  Our  goal  is  to  reduce  cut  the 
time  from  concept  to  fielding  in  half! 

3.  And  doing  so  affordably — remarkable  reducing  not  just  the  cost  to 
acquire,  but  the  total  ownership  cost. 

Complexity 

The  nature  of  products  and  processes  demanded  by  today’s  global 
market  place  is  changing.  So  are  the  products  required  by  our  defense’s 
warfighters  and  strategies.  People  often  speak  of  the  past  as  being  a 
simpler  time.  We  frequently  emote  that  “things  were  not  nearly  as 
complicated.”  In  light  conversations,  we  “complain”  that  “back  then”  we 
didn’t  have  to  choose  between  paper  and  plastic,  regular  and  decaf,  or  even 
between  latte’  and  cappuccino. 

It  turns  out  that  those  conversations  are  not  among  persons  who  are 
imagining  things.  If  you  put  today’s  economy  under  a  microscope,  the  past 
really  was  a  simpler  time — at  least  from  a  product  and  process  point  of 
view.  A  recent  found  that  the  most  successful  commercial  technologies 


have  changed  in  one  basic  way  over  the  past  quarter  century:  they  have 
become  more  complex. 

It  looked  at  the  30  most  valuable  exports  in  the  global  market  in  1970 
and  those  of  today.  They  found  in  1970  nearly  60  percent  of  the  world’s 
top  exports  were  essentially  simple  products  that  could  be  manufactured 
through  simple  processes.  Today,  that  same  percentage — 60  percent — of 
the  world’s  top  exports  are  complex  products  that  require  complex 
manufacturing  processes. 

For  example,  25  years  ago,  typewriters  were  one  of  the  top  products; 
now  its  PCs.  And  our  audio  players  that  were  based  on  Thomas  Edison’s 
phonograph  have  been  replaced  by  CD  players  that  rely  on  computer  chips 
and  lasers.  Certainly,  those  technologies  that  Joint  Vision  2010  will  rely  on- 
-low  observable  masking  technologies,  smarter  weapons,  long-range 
precision  capability  and  information  technologies — all  technologies  that  were 
unknown  a  quarter  century  ago— are  more  complex  than  those  of  25  years 
ago. 


Put  simply,  the  future  belongs  to  those  who  can  make  sense  of  the 
complex,  to  those  that  can  take  an  idea  from  conception  through  the 
functional  integration  of  many  complex  technologies  and  disciplines  to 
product  realization,  to  those  who  can  put  complex  technologies  and 
products  “out  the  door  ”  and  into  the  hands  of  users. 

Today  I  will  address  five  specific  aspects  of  our  strategy  for  meeting 
the  RMA  and  RBA  that  I  believe  have  particularly  high  leverage  for  us: 

•  Integrated  Product  and  Process  Development 

•  Simulation  Based  Acquisition 

•  Improved  Software  Engineering 

•  Design  for  Ownership 

•  Open  Systems  Approach 

Integrated  Product  and  Process  Development 

Success  in  this  era  will  occur  when  different  approaches  and 
perspectives  are  brought  together.  The  final  value  added  is  always  greater 
than  the  sum  of  the  parts.  This  places  a  premium  on  qualities  that  we 
sometimes  undervalue  as  a  society:  qualities  like  diversity,  trust  and 


community,  and  it  requires  that  we  develop  an  ability  to  bring  together  and 
reconcile  those  differing  perspectives  and  approaches. 

In  order  to  do  that,  the  Department  has  worked  to  find  the  best 
methods  for  reengineering  its  processes.  In  May  1995  the  Secretary  of 
Defense — then  Bill  Perry— directed  a  “fundamental  change  in  the  way  we 
acquire  goods  and  services”  and  mandated  that  the  concepts  of  Integrated 
Product  and  Process  Development  (IPPD)  and  Integrated  Product  Teams 
(IPTs)  “be  applied  throughout  the  acquisition  process  to  the  maximum 
extent  possible.” 

The  DoD  defines  IPPD  as  “a  management  process  that  integrates  all 
activities  from  product  concept  through  production/field  support,  using  a 
multifunctional  team,  to  simultaneously  optimize  the  product  and  its 
manufacturing  and  sustainment  processes  to  meet  cost  and  performance 
objectives.”  An  outgrowth  of  concurrent  engineering  practices,  the  IPPD 
process  reflects  a  systems  engineering  approach  that  has  incorporated 
sound  business  practices  and  commonsense  decision-making.  Fundamental 
to  the  successful  implementation  of  the  IPPD  concept  will  be  the 
willingness  of  organizations  to  undertake  and  experience  profound  changes 
in  their  cultures  and  past  practices. 

IPPD  has  had  many  successes  in  industry  and  it  fits  well  within  the 
spirit  of  the  Department’s  acquisition  reform  initiatives.  It  is  being 
accomplished  by  integrating  the  “functional  stovepipes,”  utilizing  best 
commercial  practices,  and  encouraging  teamwork  within  the  Department 
and  between  ourselves  and  industry. 

At  the  core  of  the  IPPD  implementation  are  Integrated  Product 
Teams  (IPTs)  that  organize  for  and  accomplish  tasks  that  acquire  goods 
and  services. 

IPPD  Key  Tenets 

To  implement  IPPD  effectively  it  has  been  important  for  us  to 
understand  the  interrelated  tenets  inherent  in  it. 

The  first  of  these  is  customer  focus.  The  primary  objective  of 
IPPD  is  to  identify  and  satisfy  the  customer’s  needs  better,  faster,  and  at 
less  cost.  The  customer’s  needs  should  determine  the  nature  of  the  product 


and  its  associated  processes.  And  to  be  precise,  within  DoD  the  customer 
is  not  the  program  manager,  but  the  warfighter. 

A  second  tenet  is  that  processes  should  be  developed  concurrently 
with  the  products  they  support.  It  is  critical  that  the  processes  used  to 
manage,  develop,  manufacture,  verify,  test,  deploy,  operate,  support,  train 
people,  and  eventually  dispose  of  the  product  be  considered  during  product 
design  and  development.  Product  and  process  design  and  performance 
should  be  kept  in  balance  to  achieve  life-cycle  cost  and  effectiveness 
objectives.  Early  integration  of  design  elements  can  result  in  lower  costs  by 
requiring  fewer  costly  changes  late  in  the  development  process.  Early  and 
continuous  life  cycle  planning  is  essential. 

Third,  the  government's  interface  with  industry  is  critical  to  IPPD 
success.  Our  requests  for  proposals  (RFPs)  and  contracts  should  provide 
maximum  flexibility  for  employment  of  IPPD  principles  and  use  of 
industry’s  processes  and  commercial  specifications,  standards,  and 
practices.  They  should  also  accommodate  changes  in  requirements  and 
incentivize  industry  to  challenge  requirements  and  offer  alternative  solutions 
which  provide  cost-effectiveness. 

Fourth  for  IPPD,  an  event  driven  scheduling  framework  should  be 
established  which  relates  program  events  to  their  associated 
accomplishments  and  accomplishment  criteria.  An  event  is  considered 
complete  only  when  the  accomplishments  associated  with  that  event  have 
reached  completion  as  measured  by  the  defined  criteria. 

Proactive  identification  and  management  of  cost,  schedule,  and 
technical  risk  is  fundamental.  Technical  and  business  performance 
measurement  plans,  with  appropriate  metrics,  should  be  developed  and 
compared  to  best-in-class  government  and  industry  benchmarks  to  provide 
continuing  verification  of  the  effectiveness  and  degree  of  anticipated  and 
actual  achievement  of  technical  and  business  parameters. 

Without  a  doubt,  the  most  essential  tenet  of  IPPD  is  multidisciplinary 
teamwork.  Inherently  IPPD  will  not  work  without  the  people  part,  which 
brings  us  back  to  the  diversity  issue  I  mentioned  earlier — previously 
separate  communities  working  together — for  common  objectives.  This  is 
teaming.  Integrated  Product  Teams  are  cross-functional  teams  that  are 
formed  for  the  specific  purpose  of  delivering  a  product  for  an  external  or 


internal  customer.  IPT  members,  as  I  must  emphasize,  should  have 
complementary  skills  and  be  committed  to  a  common  purpose.  The  right 
people  at  the  right  place  at  the  right  time  are  required  to  make  timely 
decisions. 

Critical  to  the  formation  of  a  successful  IPT  are:  (1)  all  functional 
disciplines  influencing  the  product  throughout  its  lifetime  should  be 
represented  on  the  team;  (2)  a  clear  understanding  of  the  team’s  goals, 
responsibilities,  and  authority  should  be  established  among  the  business  unit 
manager,  program  and  functional  managers,  as  well  as  the  IPT;  and  (3) 
identification  of  resource  requirements  such  as  staffing,  funding,  and 
facilities. 

Also  critical  is  empowerment.  Decisionmaking  should  be  driven  to 
the  lowest  possible  level  commensurate  with  risk.  The  team  should  be 
given  the  authority,  responsibility,  an  resources  to  manage  its  product  and 
its  risk  commensurate  with  the  team’s  capabilities.  The  authority  of  the 
team  members  needs  to  be  defined  and  understood  by  the  individual  team 
members.  The  team,  on  the  other  hand,  should  accept  responsibility  and  be 
held  accountable  for  the  results  of  its  efforts. 

I’ve  spoken  some  about  IPPD  as  a  process  and  some  about  people, 
but  let  me  shift  to  a  third  focus  area:  tools.  It  is  incumbent  on  both  DoD 
and  industry  to  employ  state-of-the-art  methods  and  tools,  to  become 
knowledgeable  of  the  capabilities  of  those  tools,  and  to  integrate  them  into 
their  internal  tools  sets  for  planning,  information  management,  design,  cost 
trade-off  analysis,  and  modeling  and  simulation. 

And  while  various  tools  are  important  I  would  like  to  draw  particular 
attention  to  virtual  prototyping  as  a  process  for  replacing  physical 
prototypes  by  computational  prototypes  which  can  be  embedded  in  realistic 
synthetic  environments  to  support  all  phases  of  IPPD.  This  we  are  calling 
Simulation  Based  Acquisition. 

Simulation  Based  Acquisition  (SBA) 

The  Defense  Department,  in  cooperation  with  our  industry  partners, 
envisions  an  acquisition  process  enabled  by  the  robust,  collaborative  use  of 
simulation  technology  that  is  integrated  across  acquisition  phases  and 
programs.  The  objectives  of  Simulation  Based  Acquisition  (SBA)  are  to: 
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(1)  Substantially  reduce  the  time,  resources,  and  risk  associated  with  the 
acquisition  process; 

(2)  Increase  the  quality,  military  utility,  and  supportability  of  systems 
developed  and  fielded;  while  reducing  their  operating  and  sustaining 
costs,  and 

(3)  Enable  integrated  product  and  process  development  across  the  full 
acquisition  life  cycle. 

I  will  not  speak  long  on  SBA  since  I  know  it  will  be  addressed  in 
some  detail  later  this  morning,  but  let  me  just  state  that  I  am  convinced  that 
there  is  consistent  and  pervasive  evidence  already  accumulated  regarding 
the  value  of  a  simulation-based  approach  to  acquisition.  Both  commercial 
and  military  programs  provide  substantial  proof  of  tangible  results  that  can 
be  measured  in  terms  of  improvements  in  cost,  schedule,  productivity, 
and  quality/performance. 

It  is  clear  that  integrated  product  and  process  development,  backed 
by  a  strong  commitment  to  computer-based  modeling  and  simulation  tools, 
provides  a  dominant  and  competitive  edge  in  the  commercial  marketplace 
and  a  distinct  warfighting  advantage  on  the  battlefield. 

Software  Engineering  Improvement 

Let  me  turn  your  attention  now  to  an  area  of  powerful  leverage  for 
the  Department— software.  There  has  been  nothing  like  the  headlong  rush  to 
software  since  the  similar  rush  to  electronics  after  WWI.  The  average 
automobile  of  today  has  more  software  in  it  than  the  first  Apollo  spacecraft 
to  arrive  at  the  moon  30  years  ago. 

We  are  just  beginning  to  appreciate  that  a  new  breed  of  “knowledge 
warriors”  is  emerging — recognizing  that  knowledge  can  win,  or  prevent, 
wars.  And  this  is  causing  fundamental  changes  in  what  is  important  to  our 
warfighting  capability. 

In  the  Gulf  War,  television  cameras,  ravenous  for  dramatic  visuals, 
focused  on  F- 14s  roaring  off  the  decks  of  carriers,  Apache  helicopters 
swooping  over  the  desert,  M1A1  Abrams  tanks  growling  over  the  sands, 
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and  Tomahawk  missiles  singing  out  their  targets.  Pieces  of  hardware 
became  overnight  stars.  But  the  real  star  was  the  invisible  software  that 
processed,  analyzed,  and  distributed  data,  though  no  television  watcher  ever 
saw  those  who  produced  and  maintained  it — America’s  software  soldiers. 

Software  is  changing  military  balances  in  the  world.  Today  weapons 
systems  are  mounted  on  or  delivered  by  what  we  call  “platforms” — a 
missile,  a  plane,  a  ship,  or  even  a  truck.  And  what  we  are  learning  is  that 
cheap,  low-tech  platforms  that  are  operated  by  even  poor,  small  nations  can 
now  deliver  high-tech  smart  firepower — if  the  weapons  themselves  are 
equipped  with  smart  software.  Stupid  bombs  can  have  their  IQ  raised  by 
the  addition  of  retrofitted  components  dependent  on  software  for  their 
manufacture  or  operation. 

Costs  of  Software  Failure 

Information  or  knowledge  superiority  may  win  wars.  But  that 
superiority  is  exceedingly  fragile.  Pentagon  leaders  have  been  stunned  in 
recent  months,  both  by  learning  that  some  of  our  computer  systems  have 
been  tampered  with  by  hackers  and  by  a  recent  military  exercise,  Eligible 
Receiver,  that  demonstrated  how  easy  it  is  for  hackers  to  cripple  U.S. 
military  and  civilian  computer  networks. 

But  my  issue  for  you  here  today  is  not  so  much  one  of  information 
assurance — although  that  is  decidedly  a  top  priority  for  the  Department.  • 
Rather  I  want  you  to  focus  on  the  implication  that  you  succeed  or  fail  on 
the  software.  It  doesn’t  matter  how  much  speed,  or  how  much  stealth  or 
how  much  armor  plating  you  have;  you  won’t  succeed  if  the  software 
doesn’t  work. 

So  I  contend  that  software  that  does  not  work  is  self-inflicted 
information  warfare.  And  the  policies,  processes,  and  practices  that  guide 
the  development  and  use  of  information  technology  in  general,  and  software 
in  particular,  are  a  crucial  component  of  knowledge  strategy. 

Expectations 

Unfortunately  our  overall  track  record — or  the  perception 
thereof — for  producing  quality  software  is  underwhelming.  According  to 


the  results  of  a  study  on  U.S.  software  development  reported  by  the 
Standish  Group  in  1996: 

•  In  1995,  only  16  percent  of  software  projects  were  expected  to 
finish  on  time  and  on  budget. 

•An  estimated  53  percent  of  projects  will  cost  nearly  190  percent  of 
their  original  estimates. 

•  Projects  completed  by  the  largest  American  organizations  have 
only  42  percent  of  the  originally  proposed  features  and  functions. 

This  sort  of  performance  record  might  somehow  be  adequate  in  a 
word  processor,  but  it  hardly  seems  acceptable  in  a  weapon  system  or 
where  safety  is  a  major  consideration.  After  all,  a  soldier  without  a  weapon 
is  at  best  a  tourist,  and  more  likely  a  target. 

Systems  Engineering  Process 

When  we  track  successful  software  developments,  almost  invariably 
the  accomplishment  can  be  linked  to  the  existence  of  a  good  systems 
engineering  processes.  It  is  for  this  reason  that  my  office  is  responsible 
for  software  acquisition  policy  in  the  Department.  Not  because  we  are  the 
focal  point  for  information  technology — because  we  aren’t.  Not  because 
we  are  the  office  of  primary  responsibility  for  software  tools  and 
technology — because  we  aren’t  either.  But  because  it  is  the  application  of 
the  disciplined  systems  engineering  process  that  makes  the  difference 
between  achieving  the  functionality  we  seek — in  both  hardware  and 
software. 

All  of  the  primary  systems  engineering  processes  must  come  together 
for  both  hardware  and  software  systems  development.  But  I  will  highlight 
two  specific  aspects  here:  Requirements  management  and  design  for 
sustainability. 

Requirements  Management 

I  have  a  cartoon  in  my  office  that  shows  two 
individuals — presumably  software  engineers — with  one  of  them  saying  to 
the  other  as  he  is  running  out,  “You  start  coding,  and  I’ll  go  find  out  what 
they  want.”  Unfortunately  there  is  all  too  much  truth  in  this  picture. 
Because  what  is  being  developed  is  “only  software” — and  everyone  knows 


software  is  easy  to  change — a  disciplined  requirements  management 
process  is  all  too  frequently  lacking.  Without  requirements  analysis  up 
front,  however,  the  results  are  unsatisfied  needs,  wasted  effort,  and 
rework. 

Software  may  be  easy  to  change — at  least  relative  to  bent  metal — but 
it  can  still  be  costly  in  both  time  and  dollars.  It  is  estimated  that  rework  is 
40  percent  of  the  cost  of  development.  Metrics  collected  by  Capers  Jones 
indicate  that  the  cost  and  schedule  impact  of  defects  in  requirements  are  the 
most  expensive  of  all  defects — followed  by  a  defect  in  top  level  design 
(architecture) ,  and  finally  by  defects  in  code. 

Design  for  Sustainment 

Much  of  the  software  that  is  operational  today  will  still  be  in  service 
several  years  from  now — with  large  implications  for  total  ownership  cost. 
By  way  of  example,  an  assessment  was  made  for  the  Air  Force  recently  of 
the  current  process  for  updating  the  software  in  major  operational  weapon 
systems.  Such  software  is  embodied  in  formally  designated  Operational 
Flight  Programs  (OFPs) .  Over  the  service  life  of  software  intensive  aircraft 
and  smart  munitions  there  is  a  need  for  continuous  improvement, 
correction,  and  addition  of  new  capability  via  software  modification. 

Over  the  FYDP,  the  combined  B-l,  F-15,  and  F-16  programs  alone 
are  projected  to  spend  nearly  one  billion  dollars  on  OFPs.  When  the  planned 
expenditures  for  the  B-2,  F-22,  F-117,  and  the  advanced  weapons  are  added 
in,  the  total  five  years  costs  of  OFPs  is  nearly  two  billion  dollars. 

As  I  noted  earlier,  approximately  66  percent  of  DoD’s  software  costs 
are  associated  with  maintenance.  Almost  all  of  the  systems  engineering 
practices  that  have  high  leverage  for  lowering  the  cost  of  maintenance  are 
practices  that  need  to  be  implemented  during  development.  These  include 
development  practices  that  reduce  that  density  of  defects  in  the  software 
delivered  into  operation;  effective  software  test;  a  strong  configuration 
management  program;  and  taking  account  early  in  the  program  of  the 
engineering  environment  and  processes  that  need  to  be  in  place  for 
sustainment. 

Design  for  Ownership 


Of  course,  software  is  not  the  only  component  of  systems  that  needs 
to  be  designed  with  sustainment  in  mind.  A  large  area  of  leverage  for  the 
Department  as  we  seek  to  reduce  the  total  cost  of  ownership  for  our 
systems  is  what  I  will  call  “Designing  for  Ownership.”  Let  me  explain. 

On  the  average,  ninety  percent  of  the  cost  of  owning  a  weapons 
system  is  determined  in  the  first  few  years  of  development — with  sixty  to 
eighty  percent  of  that  ownership  cost  being  operations  and  sustainment. 
Acquisition  costs — design,  test,  fabrication,... -are  really  only  a  relatively 
small  fraction  of  total  ownership  costs. 

Operations  costs  are  driven  by  things  like  consumables — fuel, 
ammunition — and  personnel,  a  large  cost  driver.  Support  costs  are  a  factor 
of  maintenance  labor,  repair  materials,  replenishment  spares,  and  the  like. 
These  are  all  factors  that  are  designed  into  the  system  we  will  own. 

This  is  one  of  the  reasons  why  acquisition  logistics  is  so  critical. 
Acquisition  logistics  is  multi-functional,  technical  management  discipline 
associated  with  the  design,  development,  test,  production,  fielding,  and 
sustainment,  and  improvement  of  systems.  Its  principal  objective  is 
ensuring  that  support  considerations  are  an  integral  part  of  the  system’s 
design  requirements,  that  the  system  can  be  cost-effectively  supported 
through  its  life  cycle,  and  that  the  infrastructure  elements  necessary  for  the 
initial  fielding  and  operational  support  of  the  system  are  identified  and 
developed  and  acquired. 

Acquisition  logistics  activities  are  the  most  effective  when  they  are 
integral  to  both  the  contractor’s  and  the  government’s  system  engineering 
technical  and  management  processes.  When  this  is  the  case,  system 
designers,  acquisition  logisticians,  and  program  managers  are  best  able  to 
identify,  consider,  and  tradeoff  support  considerations  with  other  system 
cost,  schedule  and  performance  parameters. 

The  Open  Systems  Approach  to  Weapons  System  Design 

Another  one  of  the  ways  we  can  design  with  life  cycle  considerations 
in  mind  is  the  open  systems  approach  to  weapons  system  design  which  is 
both  a  technical  approach  and  a  preferred  business  strategy  thafallows  DoD 
to  field  superior  combat  capability  quicker  and  at  a  more  affordable  cost. 


The  open  systems  approach  defines  key  interfaces  for  a  system  (or 
piece  of  equipment)  being  developed.  Interfaces  generally  are  best  defined 
by  formal  consensus  (adopted  by  recognized  industry  standards  bodies) 
specifications  and  standards.  However,  commonly  accepted  (de  facto) 
specifications  and  standards  (both  company  proprietary  and  non¬ 
proprietary)  are  also  acceptable  if  they  facilitate  utilization  of  multiple 
suppliers. 

The  use  of  de  facto  specifications  and  standards  takes  advantage  of 
the  fact  that  firms,  particularly  those  in  the  commercial  arenas,  frequently 
develop  hardware,  software  and  systems  standards  of  the  design  and 
fabrication  of  computing,  telecommunications,  display,  sensing,  and  signal 
processing  systems.  Whether  interfaces  are  described  by  consensus  or  de 
facto  standards,  the  benefits  only  accrue  if  products  from  multiple  sources 
are  economically  possible.  Although  the  most  common  emphasis  is  on 
electronic  systems,  the  open  systems  approach  is  widely  applicable,  from 
fasteners  and  light  bulbs  to  jet  engines. 

An  open  systems  approach  is  designed  to  facilitate  the  use  of  widely 
accepted,  standard  products-from  multiple  suppliers-in  DoD  weapons 
systems.  In  addition,  if  the  architecture  is  defined  by  specifications  and 
standards  used  in  the  private  sector,  the  DoD  can  be  one  of  many 
customers  to  leverage  the  benefits  of  the  commercial  marketplace,  taking 
advantage  of  the  competitive  pressures  which  motivate  commercial 
companies  to  reduce  prices,  and  introduce  new  products  developed  with 
internal  resources. 

The  open  systems  approach  can  have  a  profound  effect  on  the  life- 
cycle  cost  of  a  system.  Program  managers  can  have  access  to  alternative 
sources  for  the  key  subsystems  and  components  to  construct  DoD 
systems.  DoD  investment  early  in  the  life-cycle  is  reduced  since  at  least 
some  of  the  required  subsystems  or  components  are  likely  to  already  be 
available,  or  being  developed  without  direct  DoD  investment.  Production 
sources  can  be  competitively  selected  from  multiple  competitors. 

The  system  design  flexibility  inherent  in  the  open  system  approach, 
and  the  more  widespread  availability  of  conforming  commercial  products, 
mitigates  potential  problems  associated  with  a  diminishing  defense- 
dependent  manufacturing  base.  Finally,  life-cycle  costs  are  reduced  by  a 


long-lived,  standards  based  architecture  that  facilitates  upgrades  by 
incremental  technology  insertion,  rather  than  by  large  scale  system  redesign. 

The  system  architecture  should  be  addressed  early  in  a  program  to 
maximize  the  number  of  potential  solutions,  and  thereby  help  reduce 
program  cost.  By  developing  the  architecture  early  in  a  program,  the 
specific  technology  used  in  its  implementation  can  then  be  chosen  as  late 
as  possible. 

The  application  of  the  open  systems  approach  to  legacy  systems  is 
less  obvious  but  still  beneficial.  Legacy  systems  usually  have  size,  space, 
power,  cooling  and  shape  factor  constraints.  For  these  systems,  the  open 
systems  approach  can  provide  form-fit-function  interface  (F3I)  solutions 
within  existing  packaging,  power,  and  environmental  constraints.  In  such 
cases,  the  open  systems  solution  frequently  requires  less  system  resources 
by  using  newer,  more  efficient  technologies.  The  open  systems  approach  is 
similar  to  F3I  except  that  the  open  systems  approach  emphasizes  choosing 
interfaces  that  are  broadly  accepted  in  the  marketplace  to  allow  for  as  many 
suppliers  as  possible  over  the  long  term. 

Closing 

At  the  end  of  the  day  we  will  field  a  Joint  Force  of  unmatched 
capability  and  versatility.  How  good  will  we  be?  Let  me  paint  a  picture  for 
you. 


In  the  Joint  Force  of  2010,  we'll  be  able  to  detect  the  launch  of  a 
ballistic  missile,  identify,  target  and  attack  the  launch  platform,  alert  all  units 
in  the  impact  area,  and  attack  and  destroy  the  incoming  missile  all  in  a 
matter  of  a  very  few  seconds.  The  ability  to  transfer  information  that  fast, 
across  service  and  even  national  boundaries,  in  the  fog  and  friction  of  war, 
using  joint  language  that  we  all  understand,  will  be  nothing  less  than 
revolutionary. 

Most  of  you  are  probably  thinking  this  is  General  Shelton’s  job,  or 
Secretary  Cohen’s,  but  it's  really  not.  It's  your  job,  because  only  you  and 
your  counterparts  can  make  this  happen  on  the  battlefield.  I  expect  every 
acquisition  professional  to  be  part  of  the  team  making  our  national  strategy 
work — making  Joint  Vision  2010  a  reality.  Remember,  your  theme  is 
“meeting  the  technology  needs  of  the  warfighter  in  the  year  2000  and 


beyond.”  Remember  also  that  our  challenges  include  not  only  meeting 
those  technology  needs,  but  doing  so  quickly  and  affordably. 

I  have  discussed  a  number  of  strategies  or  initiatives  that  I  believe  will 
contribute  to  engaging  those  challenges — IPPD,  Simulation  Based 
Acquisition,  improved  software  engineering,  designing  with  total  ownership 
in  mind,  and  open  systems  approaches.  Undoubtedly  these  strategies  and 
others  will  be  discussed  in  more  detail  here  this  week. 

Because  of  the  unprecedented  opportunities  and  challenges  emerging 
from  the  rapidly  changing  technologies  enveloping  us  today,  I  cannot 
emphasize  too  much  our  need  to  work  together  to  succeed.  We  must  rely 
on  each  other  now  more  than  ever  before. 

The  fact  that  our  economy,  and  indeed  our  way  of  life,  and  certainly 
our  defense,  is  now  shaped  and  dominated  by  technological  products  of 
inordinate  complexity  means  that  we  must  see  beyond  the  limits  of  our 
individual  perspectives  and  achieve  the  breakthroughs  that  occur  only 
through  the  synthesis  of  widely  different  skills  and  points  of  view.  True 
progress  within  an  envelop  of  complexity  occurs  only  through  an 
appreciation  of  mutual  benefit. 

Whatever  our  individual  challenges,  if  we  join  our  talents  and  work 
together,  we  can  and  will  meet  those  challenges. 

Many  of  the  discussions  on  the  agenda  for  this  symposium  will 
address  what  you  are  doing  to  “meet  the  technology  needs  of  the 
warfighter.”  Peter  Drucker  has  said  that  ours  is  a  world  in  which 
knowledge,  not  labor,  not  raw  materials,  not  capital,  but  knowledge,  is  the 
key  resource  .  This  meeting  is  your  opportunity  to  increase  your 
knowledge,  and  to  share  your  knowledge.  I  strongly  encourage  you  to  take 
the  maximum  advantage  of  this  opportunity. 
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Institutionalize  IPPD  in  DoD...DMC,  April  1995 


DoD  Acquisition  Reform  -  major  goals 
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Improve  the  software  procurement  process 
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Defense  Systems  Affordability  Council  (DS AC) 
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*  Exec  Comm  members/reps  also  participate  in  Plenary  Group 
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models  &  attach  elements  of  sustainment  cycle  times 

Realistic  programming  &  program  stability  are 
essential  -  integrated  team  efforts  by  requirements, 
programming  &  acquisition  communities 


IPPD  Versus  Systems  Engineering 
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Event  driven  scheduling  contractor-unique  approaches 
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Pre-Acauisition  Re 


Pre-Acquisition  Reform  Environment 


Average  schedule 
slip  is  222% 


DoD  Acquisition  Management  Key  Policies  | 
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Our  Education  &  Training  Goal 


Our  Goal:  A  Workforce  which  can  take  advantage  of  the 
Acquisition  Process  Improvements  we  are  Implementing 


stems  Engineering  Committee 
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We  must  now  focus  on  how  to  effectively  apply  Acquisition  Reform 
lessons  learned  to  maintaining  and  upgrading  our  existing  systems. 
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application  and  technology  and  will  be  looking  for  evidence  of 
that  investment  in  program  planning  and  execution.” 
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Simulation  Based  Acquisition  - 
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INot  used  across  all  program  areas 
Limited  scope 
Unique  data  representations 
Limited  interoperability 


SB  A  Payoff 


System  Life  Time 


Simulation  Based  Acquisition  (SBA) 
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Extensive  Re-use  Within  Phases  and  Across  Acquisition  Programs 


SBA  Architecture  Views 


Conventions 


SBA  -  Not  just  Technology 
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SBA  -  A  Work  In  Progress 
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Changes  to  DoD  5000.2-R  (T&E,  Acquisition  Strategy) 
Defining  Pilot  programs 

International  Action  Group  on  SBA  processes  (under 
The  Technical  Cooperation  Program  (TTCP) 
Joint  Systems  &  Analysis  (JSA)  Group) 


-  Check  NTSA  home  page  for  additional  information 
M&S  Industry  Steering  Group  (next  chart) 


SBA  Industry  Steering  Group  Members 
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-  Acquisition  Strategy  section 

-  Test  and  Evaluation  section 


Recent  Actions  (Contfd) 
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Knowledge  Engineering  (DKE)  program  agreement  to 
collaborate  on  SB  A  pilot  projects 


Simulation,  Test  and 


|  STEP 

STEP  is  a  sub-process  of  SBA 


STEP  Guidelines 
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STEP  Guidelines  Approval 


Leadership  Directive 
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What  is  needed  to  infuse  M&S  into  the  T&E 
process 

Are  you  prepared  to  perform  VV  &  A? 


Example 


H  ofggf  E  F|^ffecf  s:  j|esti  ng 


User  unilaterally  develops  and  9.  Tester  assists  in  developing 

evaluates  requirements  requirements  trade-space 

DT &E  and  OT &E  independent  10.  DT &E  and  OT &E  partnership 

and  sequential 
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Abstract 

The  U.S.  Navy  has  not  operationally  deployed  obscurant  smoke  to  hide  capital  ships  from  being 
targeted  by  enemy  gunners  for  many  years.  One  serious  drawback  to  the  use  of  a  smoke  cloud  to 
cover  a  ship  is  that  the  obscured  ship  also  cannot  accurately  target  the  enemy.  However  with  the 
sensors  and  guidance  systems  of  today’s  anti-ship  missiles,  the  older  obscurant  clouds  represented  by 
fog  oil  type  smoke  pots  will  not  be  effective  to  mask  a  ship  from  many  advanced  sensors.  With  the 
use  of  new  additives  and/or  new  compositions,  missiles’  sensors  can  be  blocked  from  achieving  lock 
onto  targets.  Smoke  deployment  of  the  obscurant  where  the  cloud  passes  over  the  ship  is  not 
advisable  due  to  the  effects  on  ship  sensors,  gun/missile  defensive  systems  as  well  as  toxic  effects  of 
the  smoke  cloud  on  ship’s  personnel. 

Smoke  on  the  horizon  will  place  the  obscurant  cloud  at  a  distance  between  the  ship  and  the 
threatening  missile.  With  the  advent  of  the  Navy’s  cooperative  engagement  capability  (CEC), 
multiple  ship  and  air  sensors’  data  are  distributed  throughout  a  battle  fleet  by  a  discrete  data  link. 
Engagements  are  moving  from  a  platform  centered  logic  to  a  network  centered  logic.  A  single  ship 
now  has  sensor  eyes  both  from  its  own  onboard  systems  in  addition  to  other  sensors  from  other  units 
of  the  battle  group  both  in  the  air  and  on  the  surface.  Threat  data  can  be  automatically  integrated  and 
implemented  to  either  spoof  the  threat  or  destroy  it  based  on  a  preset  computational  decision 
process.  Threat  speed,  angle  of  arrival  (AO A),  time  of  arrival  (TO A),  and  the  situational  awareness 
(SA)  of  the  fleet  units  positions,  speed  and  direction  will  be  known  as  the  threat  data  from  multiple 
sensors  are  integrated.  Decision  processes  will  automatically  take  the  most  appropriate  defensive 
actions  based  on  continuous  updates  of  the  theat’s  position  &  heading  direction.  Smoke  will  be  one 
component  of  a  two  component  countermeasure  system.  The  second  component  would  be  the 
decoy,  either  infrared  (IR)  or  radio  frequency  (RF).  The  decoy  would  be  launched  to  the  periphery  of 
the  smoke  cloud,  within  the  field  of  view  of  the  missile.  With  the  presence  of  the  ship  obscured  from 
the  threat  missile,  only  the  decoy  would  be  viewed.  Even  missile  seekers  with  decoy  discrimination 
capability  would  find  it  impossible  to  discriminate  the  decoy  from  a  ship  it  could  not  sense. 
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INTRODUCTION 

Naval  capital  ships  have  over  the  last  40  years  traditionally  operated  in  an  open  ocean,  blue  water 
scenario.  Conflict  with  opposing  naval  forces  would  occur  far  from  shore  defensive  forces.  Today, 
littoral  warfare  envisions  U.S.  Naval  forces  much  closer  to  shore  to  support  numerous  operations 
such  as  amphibious  landing  and  rescue.  Battle  fleet  defense  can  no  longer  be  completely  assured  by  a 
500  mile  radius  protection  zone  around  the  Battle  Fleet  with  fleet  aircraft.  In  some  cases,  fixed  or 
mobile  enemy  defense  systems  could  engage  Naval  ships  from  shore  emplacements  or  from  aircraft 
that  can  target  Naval  vessels  soon  after  launch  from  enemy  airfields.  Ship  defensive  systems  may  be 
degraded  due  to  the  proximity  of  land  masses  on  ship  targeting  sensors  or  other  considerations  such 
as  political  impacts  from  launching  missiles  into  busy  commercial  airways.  Decoys  on  the  other  hand 
are  comparatively  benign  to  the  political  environment  and  if  effectively  used  would  provide  the 
protection  needed  in  the  littoral  zone.  The  issue  this  paper  addresses  is  the  use  of  obscurants  capable 
of  masking  ship  signatures  in  both  the  infrared  (IR)  and  radio  frequency  (RF)  spectrum  and  how  the 
obscurants  should  be  integrated  into  a  network  centered  response.  These  obscurants  combined  with 
RF  &  IR  decoys  would  provide  for  a  much  more  effective  countermeasure  (CM)  system  than 
employment  of  either  in  a  singular  mode. 


SCOPE  OF  PAPER 

This  paper  will  present  a  radical  concept  to  naval  thinkers.  Traditional  views  of  smoke  were  correct 
when  smoke  was  employed  to  hide  a  vessel  as  it  scurried  away  from  a  conflict  it  wanted  to  leave 
safely.  However  this  paper  will  make  the  case  for  the  use  of  smoke/obscurant  throughout  the  course 
of  a  conflict.  No  particular  delivery  system  will  be  identified  as  the  “one”  to  use,  and  this  paper  will 
not  identify  the  most  appropriate  smoke/obscurant  compositions.  A  case  will  be  made  to  support  the 
concept  that  the  U.S.  Navy  must  begin  to  seriously  study  the  protection  of  capital  ships  with  decoys 
and  obscurant  systems  working  in  a  complimentary  fashion.  What  is  discussed  is  how  an  inherently 
platform  centered  action  such  as  individual  ship  self-protection  can  be  made  more  effective  through  a 
network  centered  countermeasure  system  using  an  integrated  decoy  with  smoke/obscurant  response. 

ISSUES  OF  CURRENT  COUNTERMEASURE  SYSTEM 

Advanced  missiles  with  flare  rejection  and  imager  guidance  use  advanced  techniques  to  locate  the 
target  and  be  able  to  discriminate  the  target  from  its  decoys.  These  missiles  use  advanced  decoy 
rejection  techniques  that  operate  to  segregate  the  ship  from  the  decoy  by  comparing  the  IR  image  of 
the  ship  and  that  of  the  decoy.  Also  spacial  location  of  the  ship  and  decoy,  spectral  characteristics  of 
the  ship  versus  that  of  the  decoy’s  composition,  and  other  notable  differences 
are  used  to  discriminate  the  ship  from  the  decoy. 
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The  Phase  II  Ship  Infrared  Countermeasure  Study  conducted  by  the  Naval  Research  Laboratory1 
listed  a  number  of  current  missiles  operating  with  imager  seekers.  By  the  year  2005,  most  countries 
who  currently  operate  anti-shipping  missiles  will  have  imager  guided  missiles.  This  is  critical  due  to 
the  inherent  countermeasure  resistance  shown  by  missiles  that  have  imager  seekers.  With  missile 
lethality  advancing,  seeker  designs  are  harder  to  defeat  by  CM.  Dual  mode  seekers  (IR/RF),  IR 
imaging,  and  RF/MMW  designs  are  being  introduced  by  the  arms  makers.  Smoke/obscurant 
technology  developed  for  tank  protection  has  demonstrated  both  IR  &  RF  masking.  Certain  additives 
will  reflect  the  electromagnetic  return  from  RF  seekers  much  as  chaff  decoys  do  and  IR  signatures  can 
be  blocked.  The  smoke/obscurant  must  be  positioned  between  the  ship  and  the  incoming  threat  as 
shown  in  figure  1.  Even  the  most  advanced  seeker  with  the  latest  decoy  rejection  circuitry,  would 
not  be  able  to  discriminate  a  decoy  from  the  missile’s  intended  ship  target,  if  the  missile  could  not 
sense  the  ship.  The  only  target  in  the  missile’s  field-of-view  would  be  the  decoy.  The  missile  may 
not  “like”  the  radiated  signal  of  the  decoy,  but  since  the  decoy  is  the  only  hot,  radiating  item  in  the 
missile’s  view,  it  naturally  would  guide  to  the  decoy. 

Another  issue  exists  due  to  the  evolving  nature  of  naval  warfare.  Network  centered  warfare  has  or 
soon  will  replace  the  platform  centered  approach  to  fighting  battles.  Network  implies  that  all 
weapons,  and  in  this  case  all  countermeasures,  are  orchestrated  by  a  central  entity.  This  would  most 
likely  be  a  computer  loaded  with  the  appropriate  written  code.  It  would  compile  missile  approach 
data,  tell  the  countermeasures/weapon  systems  when  to  fire,  and  follow  through  to  make  certain  the 
missile  was  decoyed  or  destroyed.  This  system  has  its  genesis  in  the  cooperative  engagement 
capability  (CEC)  which  has  begun  its  deployment  on  U.S.  vessels.  However  at  this  time,  U.S.  ships 
that  have  CEC  capability  currently  are  not  controlling  or  influencing  the  deployment  of  decoy 
countermeasures. 

One  other  issue  must  be  addressed  before  the  U.S.  Navy  can  utilize  smoke/obscurants  as  envisioned  in 
this  paper.  Placement  of  the  smoke/obscurant  cloud  must  be  accurate  and  timely.  The  current  ship 
CM  launcher,  Mk-36,  is  fixed  to  the  deck  of  the  ship.  Tube  angles  of  30  or  60  degrees  will  place 
decoys  in  only  those  places  allowed  by  the  ship/launcher  geometry.  If  different  decoy  function 
positions  would  be  needed,  the  ship  would  be  required  to  maneuver  to  a  changed  heading  prior  to 
firing.  Also,  since  the  launcher  is  not  stabilized  in  relationship  to  the  ship,  significant  ship  roll  will 
lock  out  the  launch  of  decoys  until  the  ship  regains  a  near  level  attitude. 
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1  Phase  II  Ship  Infrared  Countermeasure  Study,  Naval  Research  Laboratory,  Dr.  Greg 
Cowart,  April  1998 
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These  issues  will  be  addressed  in  the  concept  of  operation  section  of  this  paper.  They  will  be 
integrated  to  show  how  the  use  of  smokes  and  obscurant  along  with  the  CEC  and  an  improved 
decoy  launcher  and  cartridges  will  provide  the  level  of  protection  U.S.  warships  will  require  to 
accomplish  their  missions  in  the  littoral  arena. 

CONCEPT  OF  OPERATION 

The  smoke/obscurant  is  like  a  catalyst  in  a  chemical  formulation.  By  itself,  its  presence  in  the 
countermeasure  equation  is  only  part  of  the  answer.  Ship  self-protection  is  enhanced  however  when 
the  smoke  is  used  in  conjunction  with  ship  decoys.  It  is  not  by  itself,  that  smoke  is  made  effective  in 
countering  anti-shipping  missiles.  Through  the  denial  of  target  sensing  data  to  an  anti-ship  missile, 
the  missile  must  assume  the  decoy,  which  is  the  only  source  in  its  field-of-view,  is  the  intended  target. 
This  gives  the  missile  little  choice  other  than  to  guide  on  the  decoy. 

Placement  of  the  smoke/obscurant  cloud  between  the  incoming  missile  and  the  ship  is  of  critical 
importance.  Also,  placement  of  the  decoys  in  conjunction  with  the  smoke  cloud  must  insure  the 
missile,  when  decoyed,  is  seduced  away  from  the  ship.  The  decoy  must  be  positioned  such  that  it  is  in 
the  missiles  field-of-view  initially.  Ship  maneuvers  and  missile  redirection  due  to  ship  masking  must 
ultimately  direct  the  missile  away  from  the  ship.  One  important  concept  that  will  be  enhanced  by 
CEC  is  the  positioning  of  the  decoys  to  “walk”  the  missile  through  a  battle  group  using  smoke  to 
obscure  the  ships  while  using  the  decoys  to  not  only  redirect  the  missile  from  its  intended  target,  but 
also,  to  redirect  it  in  such  a  way  that  the  missile  cannot  inadvertently  reacquire  a  second  ship  by 
accident.  One  ship  decoying  a  missile  away  from  itself  only  to  direct  the  missile  into  a  second 
friendly  would  not  be  considered  a  successful  CM  experience  by  the  second  ship.  Through  the  use  of 
the  Navy’s  CEC  system,  ships  could  share  sensor  data  on  threats  from  both  surface  and  air  sensors. 
Also,  weapons  firing  can  be  accomplished  by  one  ship  directing  another  to  launch  weapons.  The 
CEC  is  a  secure  data  link  tied  to  a  central  computer  that  shares  sensor  data  as  well  as  weapons 
coordination. 

The  CM  response  for  a  Battle  Group  could  also  be  coordinated  in  such  a  way.  Incoming  threat 
data  would  be  transmitted  via  secure  data  link  from  a  P-3  to  the  Battle  Group.  Missile  trajectory 
track(s)  would  indicate  the  anticipated  targeted  ship(s)  and  the  time-of-arrival  (TOA)  of  the  missile 
on  target.  A  central  computer  on  the  targeted  ship  would  compute  the  appropriate  integrated 
(network)  Battle  Group  response.  Smoke/obscurant  munitions  would  be  dispatched  to  an  intercept 
point  1-2  miles  from  the  ship  and  deployed.  Since  the  missile’s  trajectory  is  known,  the  missile  angle 
of  arrival  (AOA)  can  be  computed  so  that  smoke  and  decoys  can  be  placed  at  the  best  location. 
Ship(s)  in  the  Battle  Group  at  the  most  adventageous  positions  would  be  issued  launch  orders  for 
smoke  and  decoys  from  the  targeted  ship’s  computer.  Since  the  Battle  Group’s  formation  is  known 
by  the  computer,  each  ships’  speed  and  direction  of  travel,  and  wind  direction  and  speed  are  known 
by  the  central  computer,  the  situational  awareness  (SA)  of  the  battle  plan  for  this  incident  is 
available. 
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Figure  1  depicts  this  incident  with  the  luring  of  the  missile  away  from  the  targeted  ship.  In  this 
simulation  of  an  attack,  the  targeted  ship  controlled  its  destiny  by  coordinating  the  response  to  the 
missile  attack.  Any  ship  in  the  Battle  Group  could  have  coordinated  the  response.  The  ships  which 
had  the  best  positions  to  fire  smoke/decoys  and  those  with  the  best  positions  to  fire  weapons  to 
destroy  the  incoming  threat  would  be  automatically  qued  by  the  computer  on  the  threatened  ship. 
Orders  to  launch  weapons  and/or  fire  decoys/smoke  would  be  sent  via  CEC  to  the  Battle  Group.  This 
whole  command  and  control  sequence  could  be  accomplished  in  seconds  during  a  real  operation. 

METHODS  OF  SMOKE  DEPLOYMENT 

Figure  2  graphically  presents  some  of  the  concepts  to  implement  smoke/obscurant  in  the  naval 
environment.  Square  2 A  of  Figure  2  illustrates  the  use  of  the  5754  naval  gun  as  the  deployment 
weapon  system.  The  projectiles  would  be  the  delivery  vehicle.  Advantages  of  this  deployment 
system  is  the  rapid  delivery  time  due  to  the  velocity  of  the  projectile  and  rapid  fire  capability  of  the 
gun.  Many  pounds  of  the  smoke/obscurant  can  be  placed  accurately  at  the  deployment  location  very 
quickly.  Also,  if  reseed  is  needed  due  to  adverse  wind  conditions,  the  5754  projectile  would  be 
responsive  in  time  and  speed.  The  projectile  design  is  a  simple  and  low  technology  bullet.  The 
costly  guidance  package  is  in  the  stabilized  gun  mount  and  aiming  hardware.  Since  no  high  cost 
guidance  is  needed  for  the  bullet,  development  costs  would  also  be  low  since  a  similar  illumination 
projectile  already  exists.  The  new  5754  cargo  round  would  be  apply  suited  to  integrate  smoke 
compositions  into  this  round  at  a  low  cost.  Disadvantages  are  that  smoke  projectiles  must  be  loaded 
along  with  high  explosive  projectiles  in  the  below  deck  loading  drums.  The  moment  a  high  explosive 
round  is  needed,  it  is  possible  that  only  smoke  projectiles  are  available. 

The  next  square,  2B  depicts  the  use  of  a  trainable  CM  dispenser  capable  of  launching  cartridges  of 
smoke  composition  and  decoys  to  nearby  locations  (around  1  mile  from  the  ship).  Advantages  of  this 
system  is  the  quick  reaction  time  for  pre-loaded  rounds.  Pre-loaded  cartridges  in  the  launcher  can  be 
fired  as  quickly  as  the  launcher  can  be  slewed.  Also,  there  are  numerous  foreign  navies  with  this  type 
system  so  development  costs  could  be  minimized  since  the  launcher  and  decoys  could  be  bought  off 
the  shelf.  The  disadvantages  are  that  the  cartridges  once  expended  must  be  hand  reloaded. 

Deployment  ranges  are  traditionally  short,  and  other  decoys  must  reside  alongside  the  smoke 
cartridges  which  lessens  the  availability  of  both  munitions. 

A  corridor  smoke  round  is  depicted  in  square  2C.  The  round’s  rocket  would  be  fired  from  a 
trainable  launcher  and  a  fuze  would  be  preset  just  prior  to  launch.  The  smoke  payload  would  be 
deployed  by  the  fuze  at  some  preselected  point  in  its  flight.  This  system  would  need  to  be  larger  in 
volume  and  weight  since  all  the  rocket  fuel  and  payload  would  be  carried  by  the  one  round. 
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This  system  would  need  to  be  developed  and  would  be  slightly  higher  in  per  unit  cost  compared  to  the 
first  two  CM  systems.  There  may  be  an  effectiveness  payback  in  that  this  concept  might  be 
programmable  to  dispense  in  a  smarter  manner  when  compared  to  projectiles  and  cartridges  that 
merely  detonate  to  spread  their  payload. 

The  last  square  2D  is  the  technology  leader  and  would  be  the  most  versatile  in  deployment  tactics. 
It  obviously  will  cost  the  most  and  will  take  the  longest  to  develop.  It  could  be  fired  from  a  vertical 
launch  tube  and  be  stored  below  deck.  It  would  be  a  stealthy  addition  to  any  ship.  It  would  leave  its 
launcher  and  fly  by  inertial  systems  to  the  exact  spot  it  is  needed.  Both  smoke  and  decoys  would  be 
on  board  and  would  be  released  at  the  proper  moment  and  location  to  maximize  effectiveness. 

IN  SUMMARY 

Littoral  warfare  could  sometimes  preclude  the  use  of  some  ship  defensive  systems 
if  collateral  civilian  or  political  damage  might  occur  from  the  use  of  high  explosive 
weapon  systems.  If  an  obscurant  is  used  to  mask  a  ship  in  conjunction  with  decoys, 
the  decoys  become  more  effective  due  the  inability  of  the  missile  to  sense  the  ship. 
Smoke/obscurants  can  be  placed  between  the  incoming  missile  and  the  targeted  ship. 

The  smoke  is  employed  at  a  distance  of  1-2  miles  from  the  ship  to  insure  should  the 
missile  continue  on  toward  the  ship,  its  defensive  weapons  will  be  brought  to  bear 
against  the  missile. 
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'EPA  issues  &  Non-toxic  Smoke  for  Warfighter  Training'  focuses  on  a  recent  and 
ongoing  'Case  Study'  using  environmentally  friendly,  machine-generated  smoke  to  simulate  the  back- 
blast  of  a  Surface-to-Air  Missile  (SAM)  Launch.  The  back-blast  is  a  visual  cue  to  help  train  the 
Warfighter  aircrew  to  avoid  being  struck  by  a  Surface-to  Air  Missile. 


We  offer  short  answers  to  the  following  questions: 

•  What  is  a  Smoky  SAM? 

•  Why  is  the  military  looking  for  visual  simulation  alternatives  for  SAM  avoidance  training? 

•  How  does  machine-generated  smoke  compare  to  Smoky  SAMs  as  a  visual  simulation? 

•  How  does  machine-generated  smoke  compare  to  Smoky  SAMs  for  environmental  friendliness, 
safety,  versatility,  ease  of  use,  and  cost? 

•  What  is  the  pilot's  perspective  of  having  back-blast  simulation  as  a  visual  cue? 

•  How  does  smoke  enhance  Militaiy  Operations  in  Urban  Terrain? 

•  What  are  some  other  applications  for  environmentally  friendly  smoke? 
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EPA  issues  &  Non-toxic  Smoke 
for  Warfighter  Training 

We  are  excited  to  share  the  very  positive  results  of  a  current  and  ongoing  evaluation  using 
environmentally  friendly,  machine-generated  smoke.  This  paper  focuses  on  a  promising,  new  back-blast 
simulation  that  will  provide  a  visual  cue  for  pilot  and  aircrew  so  they  can  avoid  being  struck  by  a 
Surface-to-Air  Missile  (S  AM). 


Background 

Surface-to-Air  Missiles 

A  substantial  back-blast  is  a  characteristic  of  the  Surface-to-Air  Missiles  like  the  (former  USSR 
Military)  SA-8  GECKO  Low  Altitude  SAM  and  the  SA-19  GRISOM,  a  radar  command-guided,  two- 
stage  SAM.  These  Surface-to-Air  Missiles  have  a  back-blast  which  is  similar  to  the  back-blast  of  a  space 
shuttle  launch,  but  on  a  much  smaller  scale.  It  is  these  larger  missiles  that  are  the  primary  concern  of  our 
visual  simulation. 

The  smaller  Man  Portable  Air  Defense  System  Missiles  (PADS)  do  not  produce  as  significant  a 
back-blast. 

Smoky  SAMs 

Smoky  SAMs  (GTR  18)  are  currently  deployed  at  Electronic  Warfare  Sites  to  provide  a  visual 
simulation  of  a  Surface-to-Air  Missile  (SAM)  Launch.  They  work  well,  functioning  in  a  manner  similar 
to  a  bottle  rocket,  and  produce  almost  no  back-blast.  They  make  a  streaming  smoke  or  condensation  trail 
on  their  way  up  to  about  1,200  feet  above  ground  level.  The  body  of  the  missile  is  made  of  a  Styrofoam¬ 
like  material. 

Problem  with  Smoky  SAMs 

Smoky  SAMs  are  NOT  available  after  the  current  (very  short)  supply  is  depleted.  This  is  true 
within  the  Commander  Naval  Air  Atlantic  (CNAL),  which  includes  the  Electronic  Warfare  Ranges  of  the 
Mid- Atlantic  Tactical  Aircrew  Combat  Training  Systems  (TACTS),  Marine  Corp  Air  Station  (MCAS) 
Cherry  Point,  NC. 

Smoky  SAMs  will  not  be  available  at  CNAL  due  to  budget  cuts.  Given  a  choice  between  real 
bullets  and  Styrofoam  training  missiles,  the  real  bullets  were  chosen. 

General  Evaluation  Information 

An  evaluation  was  conducted  on  6  May  '98  to  determine  the  suitability  of  machine-generated 
smoke  to  simulate  the  back-blast  of  a  SAM  launch.  We  worked  under  clear,  sunny  skies  with 
temperatures  approx.  80  F.  Winds  were  variable,  estimated  at  3  to  8  knots. 

SAM  Simulation  Usage  Profile 

Mr.  Larry  Roberson,  Mission  Coordinator,  Litton  PRC  asked  American  Safety  ASHP  to 
provide  a  smoke  generating  system  capable  of  simulating  SAMs  back-blast  ten  times  per  day  for  fifteen- 
seconds  per  simulation,  five  days  per  week,  four  weeks  per  month,  and  12  months  per  year.  Ideally  this 
system  would  be  serviced  monthly  since  that  is  the  normal  maintenance  cycle  for  the  Electronic  Warfare 
Range. 


Based  on  this  usage  profile  provided,  we  calculate  2,400  Electronic  SAM  launch  simulations  per 
training  Site  annually. 


Conclusion  for  SAM  Simulation 

The  initial  evaluation  proved  highly  successful.  The  MDG/TF4  Smoke  Generator  produced 
smoke,  which  was  easily  visible  to  rotary  wing  aircrew.  Visibility  was  very  good  at  3.5-miles/l,000  ft. 
and  during  the  flight  to  2-miles/500  ft.  elevation. 

Further  analysis  yielded  many  surprising  benefits,  including  greatly  minimized  environmental 
impact,  increased  safety,  expanded  capability,  greater  ease  of  use,  and  dramatic  cost  savings. 

The  recommendation  from  the  Mission  Coordinator,  Litton  PRC  is  to  purchase  and  install  one 
Th4.  Once  installed,  additional  evaluation  should  be  performed  for  rotary  wing  and  for  fixed-wing  fast- 
movers  as  a  replacement  for  Smoky  SAMs.  If  the  system  proves  viable  for  all,  a  follow-on  buy  for  other 
Electronic  Warfare  sites  is  recommended. 

Advantages  of  the  TF4  Vs  Smoky  SAMs 

The  TF  is  environmentally  much  friendlier 

Smoky  SAMs  introduce  toxic  smoke  into  the  atmosphere,  if  not  retrieved,  the  Styrofoam  rocket 
becomes  garbage  scattered  around  the  test  site.  TF4s  introduce  NO  toxic  smoke  and  NO  garbage.  The 
Th4  smoke  output  is  so  user  friendly...  MDG  Fog/Smoke  Generators  are  the  machines  of  choice  for  many 
Broadway  shows.  Audience,  stage  crew  and  actors  all  breathe  the  same  top-quality  smoke  indoors. 


The  TF  provides  safer  training 

Smoky  SAMs  pose  a  slight’  risk  during  transportation,  storage  and  handling  since  they  are  Class 
"B"  explosive.  The  threat  to  aircraft  and  crew  of  a  Styrofoam  rocket  being  drawn  into  a  turbojet  engine  is 
unknown,  but  currently  presumed  to  be  slight.  Th4s  pose  NO  risk  to  aircraft  and  crew  and  NO  risk  during 
transportation,  handling  or  storage. 

The  TF  expands  training  capability 

•  Threat  Emitters  (Electronic  Simulations)  are  often  used  without  any  visual  cues  at  all.  With  the 
Th  System  installed,  this  training  can  automatically  and  inexpensively  include  visual  simulation 
too. 

•  Many  Missions  occur  in  the  dark.  Currently  there  is  no  visual  cue  for  nighttime  simulations.  With 
the  addition  of  the  optional  illumination  Rack,  (included  in  the  Unitized  System  price)  new 
realism  and  effectiveness  can  be  achieved  during  this  important  training  scenario.  The 
illumination  System  has  not  been  tested  and  is  not  yet  completed. 

More  realistic  training  can  be  provided  since  the  Th  poses  NO  risk  to  the  aircraft  or  crew. 
Training  missions  can  be  safely  flown  at  any  level.  This  will  be  most  helpful  in  providing  visual 
cues  at  levels  of  250  to  1,000  feet,  if  Smoky  SAMs  are  in  use,  as  a  safety  precaution  at  MCAS 
Cheriy  Point  they  avoid  training  below  1,000  feet. 

At  Nellis  AFB,  training  is  conducted  with  Smoky  SAMs  at  any  altitude  (Earth  to  God) 
and  care  is  taken  to  avoid  hitting  the  aircraft. 


The  TF  is  much  easier  to  us. 

Smoky  SAMs  require  certain  personnel  certified  to  handle  this  Class  "B"  explosive.  Each 
Smokey  SAM  launch  requires  coordinated  manpower  effort  to  accomplish.  Th4s  are  non¬ 
explosive  and  NO  special  training  or  license  is  required  for  handling.  Turn  it  on  and  it's  in  the 
standby  mode  within  ten  minutes.  When  the  site  operator  "locks-on"  and  fires  an  Electronic 
SAM  Simulation,  smoke  deployment  will  be  an  automatic  consequence.  Maintenance  cycles  are 
monthly  and  can  be  completed  in  a  half-hour. 


The  TF  dramatically  lowers  cost 

The  following  figures  are  based  on  200  SAM  launch  simulations  monthly  or  2,400  annually. 


ITEM  ($)  SMOKY  SAM  ($)  TF4 

Machine  Cost . 15,740.00 

One-Year  Consumables . Missiles  220,800.00 . 2,772.00 

Five-year  Cost  Overall . 1,104,000.00 . 29,600.00 

Average  Cost  per  Simulation . 92.00 . 2A7 

Five-year  Savings . . . 1,074,400.00 

Cost  Ratio . 37 . 1 

BREAKEVEN  POINT 

to  cover  machine  cost  and  one-year  consumables . 1  month 

to  cover  machine  cost  and  five-year  consumables . 2  months 


TF4  Unitized  System 
Fluid,  Gas,  Electric 
Machine  &  Consumables 
Five-year 

with  the  TF4  Unitized  System 


with  the  TF4  Unitized  System 
with  the  TF4  Unitized  System 


What  is  the  Super  Cobra  Pilots  point  of  view? 

The  following  are  highlights  of  a  June  8,  1998  interview  with  Capt .  Sager ;  MCAS  Cherry  Poin4  NC. 

Capt  Sager  is  the  pilot  who  flew  the  May  6,  1998  TF4  evaluation  mission. 

Q  What  did  you  think  of  the  suitability  of  the  TF4  smoke  for  SAM  Avoidance  Training? 

A  If  multiple  ground  smokes  are  employed  as  well,  it  might  be  a  problem.  If  they  could  use  in 
conjunction  w/  Smoky  SAMs,  it  would  be  ideal. 

If  this  were  possible,  connect  the  smoke  machine  to  Threat  Emitters  so  they  can  get  an  electronic 
indication  too.  If  this  were  possible  then  it  would  be  an  invaluable  piece  of  gear. 

The  larger  system  (TF4)  worked  better  (than  the  MAX  5000).  Either  would  be  OK  in  open 
terrain.  In  the  trees  it  may  take  some  time  for  the  smoke  to  rise  up.  If  we  could  make  thicker  smoke,  it 
would  be  good,  especially  dealing  with  the  North  Carolina  haze.  Note:  MDC  Engineers  recommend 
adjustment  oft  the  TF4  to  have  approx .  150%  greater  output  than  the  unit  used  for  this  evaluation. 

O  How  does  the  Smoky  SAM  compare  to  the  TF4  smoke  you  saw? 

A  The  Smoky  SAM  shows  a  condensation  trail  back  toward  the  launch  area  which  is  good...  But  the 

back-blast  from  the  machine  smoke  in  the  long  run  is  likely  to  be  more . especially  if  more  portable, 

the  smoke  machine  would  be  better  than  Smoky  SAMs  would. 


Since  there  is  the  potential  for  a  Smoky  SAM  missile  to  get  sucked  into  the  intake,  they  need  to  fly  at 
1,000  feet  minimum.  But  in  combat  sometimes  they  use  Terrain  Masking  and  fly  as  low  as  the  nape-of- 
the-earth...  I  like  getting  a  visual  cue  and  being  able  to  safety  train  at  any  altitude. 


Q  If  you  had  to  choose  between  Smoky  SAM  and  Th4  smoke  with  electronic  indication  for  SAM 
Avoidance  Training,  which  would  you  prefer? 

A  It  would  be  scenario  dependent.  I'd  say  I'm  equal  on  the  two  methods.  I'd  choose  the  one 
which  is  less  expensive.  I  think  the  machine  (TF4)  may  be  even  more  useful  to  the  fixed-wing 
fast-movers  but  (I  don't  know)  -  you  have  to  ask  them...  got  to  go  to  a  mission  briefing. 


TF  Unitized  System 

The  TP  Unitized  System  is  designed  to  accommodate  monthly  maintenance  cycles  for  gas  and 
fluid  replenishment.  The  estimated  System  weight  is  200-lbs.  and  it  will  occupy  less  than  one  cubic 
meter. 

The  current  configuration  for  the  TF  Unitized  System  includes  the  following: 

•  One  Th4  Fog/Smoke  Generator 

•  One  5-gallon  pressurized  tank  for  "Neutral  Fluid" 

•  Two  20-pound  Nitrogen  Gas  Bottles. 

•  Two  "Spare"  20-pound  Nitrogen  Gas  Bottles  for  monthly  replenishment. 

•  One  "Rack"  will  provide  a  platform  to  unitize  all  the  other  elements  of  the  System. 

•  One  illumination  Rack.  For  Nighttime  SAM  launch  simulations.  We  will  provide 
Orange  light  for  illuminating  the  smoke  for  nighttime  training  operations.  We  are 
planning  for  an  all-weather  illumination  rack  that  can  be  easily  added  to  or  removed  from  the 
TF  Unitized  System.  When  connected,  this  will  also  function  as  an  automatic  consequence  of  a 
SAM  Simulation. 


Obscuration  for  Military  Operations  in  Urban 
Terrain  (MOUT) 

MDG  has  extensive  experience  with  installing  All  Weather  Th  Series  smoke  generators  in 
MOUT  facilities. 

On  May  6,  1998  we  also  conducted  a  successful  smoke  demonstration  at  the  MOUT  facility 
Camp  Lejune,  NC. 

Lt.  Co.  Fred  Hudson,  Marine  Expeditionary  Force  Wing  said  something  similar  to  the  following 
about  the  MOUT  demonstration. 

...  the  MDG  smoke  system  enables  us  to  replicate  the  environment  we  expect 
to  face  fighting  in  the  city.,  billowing  smoke  trapped  inside  building  and  the 
tight  spaces  between  buildings. 

Too  often  we  train  in  a  "clean"  environment  and  it  doesn't  challenge  the  Warfighter. 

The  Th  is  easy  to  use,  low-cost  and  weather  sturdy. 

This  will  improve  the  quality  of  training.  We  can  train  with  our  Forward  Looking 
InfraRed  (FLIR)  and  on-board  weapons  systems.,  this  will  help  show  how  weapon  systems  work 
and  what  systems  look  like  while  shooting  blanks.  This  will  raise  the  anxiety  of  the  combatants 
and  heighten  the 
realism  tremendously. 


Other  Applications  for  Non-Toxic  Smoke  Generators 

•  Emergency  Evacuation  Training 

•  Security 

•  Emergency  Ventilation  System  Testing.  The  US  Coast  Guard  is  currently  looking  at 
developing  a  standard  for  large  passenger  vessels  and  it  appears  likely  that  they  will 
choose  the  MDG  machines  for  this  program. 


Manufacturer/Dealer:  Corporate  Overview 

Since  1979  MDG  Fog  Generators.  Ltd  has  consistently  manufactured  outstanding  fog  machines. 
MDG  Fog  Generators  were  chosen  for  this  Surface-to-Air  missile  back-blast  simulation  for  several 
reasons  including: 

•  Excellent  reputation  for  producing  rugged,  reliable,  effective  and  efficient  smoke  generators. 

•  Ability  to  produce  a  high  volume  (50,000  +  Cubic  Feet  per  Mm.)  expanded  smoke  cloud  with  a 
single  machine. 

•  The  only  manufacturer  that  we  have  been  able  to  locate  that  has  an  'All  weather'  machine  that 
can  be  permanently  installed  outdoors. 

MDG  and  American  Safety  have  partnered  on  several  projects  and  have  a  successful  and  close 
manufacturer/dealer  relationship. 

American  Safety  &  Health  Promotions.  Ltd  has  been  offering  quality  products,  sales  and  marketing 
services  for  22  years.  American  Safety  is  the  dealer  &  product  specialist  for  SAM  Launch  Visual 
Simulation  and  Obscuration  for  MOUT  Training  Programs.  American  Safety  is  providing  point-of- 
contact,  shared  customer  service  responsibility,  coordination  for  product  evaluation,  and  processing  for 
orders  and  invoices. 


Other  Smoking  Application 
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Atmospheric  Support  for  Ground  Systems  Hit  Avoidance 

Modeling  Effort 
Scarlett  Ayres,  Robert  Sutherland 
U.S.  Army  Research  Laboratory 
Survivability  Lethality  Analysis  Directorate 
White  Sands  Missile  Range,  NM  88002-5501 

Abstract 

The  Army  Research  Laboratory  Survivability  Lethality  Analysis  Directorate  (ARL/SLAD)  has 
identified  for  system  analysis  studies  the  need  for  high  fidelity  computer  simulations  of  realistic 
battlefield  environments  requiring  correspondingly  high  fidelity  met/atmospheric  input  not 
currently  available  from  conventional  databases.  The  need  spans  (most)  all  SLAD  mission  areas. 
In  August  1997,  the  Tools,  Techniques,  and  Methodology  (TTM)  effort  “Atmospheric  Support 
for  Ground  Systems  Hit  Avoidance”  was  formed.  The  purpose  of  this  group  was  to  develop  high 
fidelity  meteorological/obscurant  models  in  the  FY98  and  FY99  timeframe  to  be  used  in  the 
missile  warning  systems  models  for  ground  systems  survivability  studies.  These  models  will  be 
used  to  develop  the  capability  to  predict/simulate  effects  of  obscured  atmospheres  on 
propagation  of  laser  beams  and  missile  plume  signatures  for  ground  system  defensive  aids.  The 
overall  TTM  effort  consists  of  integrating  several  existing  models;  the  Vehicle  Smoke  Protection 
Model  (VSPM),  the  Combined  Obscuration  for  Battlefield  Contaminants  (COMBIC),  the 
MODerate  resolution  Transmission  code  (MODTRAN) ,  and  the  Missile  Flyout  Model 
(FLYOUT),  with  several  models  to  be  developed;  the  Diurnal  Scale  Met  Characterization  Model 
(DAY24),  die  Missile  Signature  Propagation  Model  (MSPROP),  and  the  Laser  Propagation 
Model  (LASPROP).  The  DAY24  Generator  Model  will  provide  the  full  diurnal-cycle  and  high- 
resolution  vertical  profiles  (wind  speed,  temperature,  relative  humidity)  of  critical 
atmospheric/meteorological  parameters  for  up  to  16  stability  categories  and  22  adverse  weather 
types.  LIDAR  measurements  and  met  measurements  taken  via  met  towers  and  tetherballoons 
will  be  used  to  develop  the  model.  The  obscurant  models  will  be  run  to  compute  transmittance 
and  concentration  data  for  selected  battlefield  munitions.  The  data  will  be  used  to  develop  an 
analytical  tool  for  the  systems  analyst  to  evaluate  the  effectiveness  of  various  defensive  aids. 
MSPROP  combined  with  the  missile  FLYOUT  model  will  take  missile  signature  data  and 
compute  the  missile  signature  as  seen  by  a  Missile  Warning  Receiver  (MWR)  through  weather 
and  obscurants.  LSPROP  will  propagate  the  signal  from  a  laser  designator  through  weather  and 
obscurants  to  calculate  the  resultant  scattering  into  a  Laser  Warning  Receiver  (LWR). 

1.  Introduction 

Figure  la  presents  a  flowchart  for  the  TTM  effort  to  propagate  a  missile  signature 
through  the  atmosphere,  smoke  and  dust  to  a  MWR.  The  primary  input  for  this  effort  is  the 
measured  missile  plume  signature  data  corrected  for  the  atmospheric  losses  computed  for  the  site 
in  which  the  signature  data  was  measured.  The  purpose  of  this  TTM  effort  is  to  calculate  how 
this  data  would  change  based  upon  site-specific  met  conditions  and  battlefield  obscurants.  The 


analyst  will  choose  a  specific  location,  time  of  day,  wavelength (s)  and  pull  from  a  met  data  base 
the  parameters  needed  to  prime  the  DAY24  Generator  model.  The  DAY24  Generator  model 
will  then  produce  the  vertical  profiles  of  wind  speed,  temperature,  pressure  and  in  some  cases 
aerosol  concentration  to  be  fed  into  MODTRAN,  MSPROP  and  COMBIC/VSPM.  MODTRAN 
will  use  these  vertical  met  profiles  to  determine  atmospheric  losses  for  the  Lines  of  Sight  (LOS) 
from  the  tank  to  the  missile.  The  FLYOUT  model  is  used  to  compute  the  position  (i.e.  LOSs). 
MSPROP  role  is  to  access  the  FLYOUT  model  position  calculations,  access  the  DAY24 
Generator  vertical  profiles  of  wind,  temperature  and  pressure  and  compute  the  missile  plume 
signature,  also,  taking  into  account  the  atmospheric  losses  computed  by  MODTRAN  for  the  site, 
season  and  time  of  day  the  user  has  chosen.  COMBIC/VSPM  is  then  run  for  a  smoke  scenario 
developed  by  the  user  and  for  the  met  parameters  computed  by  the  DAY24  Generator  model  to 
compute  the  effects  of  smoke  and  dust  on  the  LOSs.  The  modified  missile  plume  signature 
computed  by  MSPROP  is  then  further  modified  by  the  obscurant  degradation  computed  by 
COMBIC/VSPM  to  compute  the  signal  that  would  enter  the  MWR.  The  analyst  can  feed  this 
modified  signature  into  existing  simulations  such  as  Hardware  In  the  Loop  (HWIL)  simulations 
or  use  a  MWR  model  to  determine  the  effects  of  smoke,  dust  and  the  environment  on  the  MWR 
ability  to  acquire  the  missile,  determine  range  to  missile,  and  determine  type  of  missile.  This 
information  will  drive  the  selections  of  the  counter-measures  (self-defense  smoke  grenades,  IR 
decoys,  jammers,  or  vehicle  movement)  to  be  deployed. 

The  TTM  effort  to  propagate  a  laser  signal  through  the  atmosphere  and  obscurants  to  the 
LWR  is  structured  fairly  similar  to  the  missile  plume  signature  propagation  effort.  The  major 
difference  is  a  Laser  Designator  Driver  model  to  compute  the  laser  designator’s  signal  instead  of 
using  measured  missile  plume  signature  data.  The  model  is  capable  of  providing  both  the  directly 
transmitted  radiation  and  multiple  scattering  from  all  directions  inside  an  obscurant  cloud.  It 
computes  the  interaction  of  photons  with  obscurant  particles  to  produce  scattering,  absorption, 
and  emission.  It  offers  the  potential  for  high  fidelity  results.  Photons  could  be  traced  to  examine 
particular  aspects  of  the  propagation  of  a  laser  designator  signal,  or  the  model  could  be  run  to 
compute  only  those  photons  that  arrive  at  a  certain  location  such  as  a  LWR  aperture.  However, 
the  Laser  Propagation  Model  main  function  is  to  propagate  the  laser  signal  through  the 
atmosphere  and  through  obscurants  to  a  LWR.  The  effort  for  fiscal  year  98  is  to  complete  a 
working  model  for  a  simple  fogoil  obscurant. 

Another  TTM  effort  that  SLAD  is  developing  models  the  reverse  problem  of  the  missile 
acquiring  the  target  (Anderson,  et.  al.,  1998).  These  developers  are  creating  a  scene  based  model 
that  will  integrate  various  sub-models  together  to  form  a  more  productive  tool  to  analyze  the 
obscurant  impact  on  a  missile’s  ability  to  detect  a  target.  Both  efforts  can  eventually  be  used  to 
as  tools  to  refine  Commander  Decisions  Aids  (CDAs).  The  CDAs  will  help  the  commander 
decided  when  to  use  smoke  or  decoys,  when  to  attack  and  when  to  maneuver.  Factors  driving 
CDAs  are  detection  range,  time  to  detect,  time  available  to  respond,  determination  of  type  of 
missile  or  laser  designator,  and  countermeasures  available. 
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Figure  la-b  Flowchart  diagram  for  a)  model  to  propagate  missile  plume  signature  to  a  MWR 
and  b)  model  to  propagate  laser  designator  signal  to  LWR. 


2 .  Measurements/Data 


Meteorological  measurements  such  as  wind  speed,  temperature  and  humidity  will  be  intensively 
collected  in  the  spring,  1998.  This  data  will  be  used  to  support  the  development  of  the  DAY24 
Generator  model.  Site  specific  met  parameters  will  be  determined  for  four  sites  of  interest  by 
accessing  weather  databases.  DAY24  will  read  in  this  data  for  the  four  sites  and  expand  the  data 
to  create  a  full- diurnal  cycle. 

2.1  Meteorological  Data 

2.1.1  Methodology 

LIDAR  data  and  met  data  will  be  collected  in  order  to  develop  the  DAY24  Generator 
model’s  ability  to  generate  full-diurnal  cycle  characterization  of  critical  atmospheric/ 
meteorological  parameters.  The  type  of  data  to  be  measured  is;  windspeed,  sensible  heat  flux, 
mixing  height,  concentration  of  aerosols,  net  radiation,  relative  humidity,  temperature  (1  m,  10 
m,  38  m),  soil  temperature  (0  cm,  10  cm,  40  cm  and  1  meter),  and  surface  temperature.  This  data 
will  be  collected  via  instrumentation  packages  attached  to  towers  and  with  the  LIDAR  in  late 
spring  of  1998  for  a  month  to  cover  the  16  possible  atmospheric  stability  categories.  Surface  and 
profile  measurements  will  be  made  primarily  at  sunset,  sunrise  and  midday.  Sunset  and  sunrise 
are  the  times  when  the  met  parameters  experience  the  most  change.  Midday  is  chosen  to  capture 
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the  “maximum”  values  of  the  met  parameters.  The  met  data  will  be  used  to  compute  the  surface 
energy  balance  budget. 

2.1.2  LIDAR 

The  LIDAR  transmits  laser  light,  which  is  scattered  off  of  air  molecules,  cloud  droplets 
and  aerosols  in  the  boundary  layer.  The  returned  light  is  collected  in  a  telescope  and  focused  on 
a  photomultiplier  detector  and  then  amplified,  digitized,  and  recorded.  The  LIDAR  can  provide 
water  vapor  profiles  and  aerosols  profiles  and  mixing  height.  A  single-wavelength  LIDAR 
system  (DRC11-3  YAG  laser,  355  nm)  will  be  used  to  measure  the  extinction  due  to  absorption 
(ozone)  and  scattering  (Rayleigh  +  aerosol).  For  the  slant  or  vertical  path  measurement  we  will 
be  using  an  upper  and  lower  bound  extinction  boundary  condition  given  by  the  LIDAR  signal 
(slope  method)  and  Rayleigh  scattering  respectively.  The  laser  runs  at  10  Hz,  and  an  average  of 
1000  laser  shots  is  taken.  The  process  lasts  about  2  minutes  of  data  gathering.  Knowledge  of  the 
extinction  profile  is  available  within  15  minutes.  The  receiver  and  transmitter  is  near  collinear 
with  the  crossover  occurring  at  about  200  meters.  Vertical  resolution  is  about  1  meter.  An 
example  of  the  extinction  profile  is  shown  in  Figure  2.  Note  that  the  mixing  layer  height  is 
clearly  evident  at  4000  meters. 
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Figure  2  LIDAR  data  showing  extinction  vs.  altitude  for  a  typical  boundary  layer 
atmosphere 


2.1.3  Met  Instrumentation 

Meteorological  measurements  in  support  of  developing  the  Day24  Generator  model  will  be 
collected  at  the  ARL/SLAD  Tower  site  located  at  White  Sands  Missile  Range  (WSMR),  NM. 
The  site  is  located  in  the  Tularosa  Basin,  southeast  of  the  post  area.  The  elevation  of  the  site  is 
-1220  m  MSL  (mean  sea  level)  and  is  characterized  by  low  desert  brush  and  grasses.  Mean  and 


turbulent  meteorological  data  is  collected  for  several  hours  in  the  morning,  noon  and  evening  in 
order  to  acquire  data  for  all  possible  atmospheric  stabilities.  Met  data  is  collected  via  two 
sources:  one  being  the  standard  range  support  at  the  range  “C”  station  and  the  other  is  specialized 
local  measurements.  Met  data  will  be  collected  at  1  m,  10  m  and  25  m.  A  tethersonde  will  be 
used  (wind  conditions  permitting)  to  collect  data  up  to  1  km.  The  tetherballon  is  an 
aerodynamically  shaped  helium-filled  plastic  balloon  that  is  tethered  to  a  winch  on  the  ground. 
Instead  of  being  blown  down-range  by  the  wind,  the  shape  allows  it  to  soar  upwards.  A  met 
sensor  package  is  suspended  a  short  distance  below  the  balloon  on  a  line  different  from  the  tether 
line.  To  make  measurements  at  a  variety  of  heights,  the  winch  is  used  to  draw  in  or  feed  out 
more  line  until  the  desired  height  is  reached.  The  balloon  is  kept  at  each  height  of  interest  for  30 
minutes  to  get  a  statistically  stable  sample,  before  changing  its  altitude.  Also,  the  balloon  can 
make  measurements  while  it  is  rising  or  descending,  allowing  soundings  to  be  recorded.  These 
balloons  are  limited  to  light  winds.  The  tethersonde  will  be  used  to  acquire  temperature, 
humidity,  pressure  and  windspeed  at  200  and  1000  meters.  Deployment  of  other  sensor 
instrumentation  is  as  follows: 

•  5103's  -  Wind  Direction  and  Wind  Speed  (2  each  at  35m,  10m  altitude) 

•  Rotronics(2)  -  Temperature  &  Relative  Humidity  =  (2  each  at  35m,  10m  altitude) 

•  Thermocouple  -  Soil  Temperature  (2  each  at  surface,  and  10cm,  40cm  and  lm  below 
surface) 

•  Infrared  Temperature  Transducers  -  Surface  Temperature  (direct  exposed  surface  & 
shaded  surface) 

•  Pyronameter  -  radiation  (2m  level) 

•  Air  Barometer  -  pressure  (lm  level) 

The  two  weatherproof  infrared  temperature  transducers  are  used  to  determine  net  surface 
radiation.  The  thermocouples  are  used  to  determine  the  heat  transfer  at  the  surface.  The  towers 
and  tethersonde  measurements  of  temperature,  humidity,  and  wind  fluctuations  are  used  to 
determine  fluxes. 

2.2  Missile  Plume  Signature  Data 


The  missile  plume  signature  data  was  collected  at  a  live-fire  test  by  the  Signature 
Measurements  Group  of  SLAD  (Cundiff,  1998).  The  data  were  collected  with  a  variety  of 
instrumentation  including  and  infrared  (IR)  Fourier  transform  spectrometer  (FTS),  an  IR  thermal 
imaging  system,  and  ultraviolet  (UV)  grating  spectrometer,  and  a  visible-to-near,  IR  grating 
spectrometer.  The  data  were  reduced  as  spectral  apparent  radiant  intensity  (data  not  corrected 
for  atmospheric  losses)  and  spectral  radiant  intensity  (data  corrected  for  atmospheric  losses 
(MODTRAN)).  Figure  3  shows  an  example  of  the  missile  plume  signature  data  collected  for  3-5 
|im. 


Figure  3  Missile  plume  signature  data 


3.  Existing  Models 
3.1  COMBIC/VSPM 

The  COMBIC  (Ayres  and  DeSutter,  1993)  computer  simulation  predicts  spatial  and 
temporal  variation  in  transmission  produced  by  various  smoke  and  dust  sources.  It  models  the 
effects  of  reduction  in  transmission  by  combining  the  munition  characteristics  with  meteorological 
information  of  an  idealized  real  world.  COMBIC  produces  transmission  histories  at  any  of  seven 
wavelength  bands  for  a  potentially  unlimited  number  of  sources  and  LOS.  It  also  computes 
concentration  length  (CL)— the  integration  of  the  concentration  over  the  LOS  path.  Phase  I  is  run 
off-line  to  compute  cloud  histories  for  each  specified  munition.  Phase  II  integrates  the  LOS  over  all 
clouds  present  on  the  battlefield  to  determine  the  CL  and  transmission.  COMBIC  uses  a  simple 
local  area  atmospheric  boundary  layer  model  where  the  wind  field  direction  and  horizontal 
windspeed  profile  are  uniform  and  static  everywhere  in  the  scenario.  Complex  terrain  and  its 
effects  on  windfield  is  not  modeled. 

The  Vehicle  Smoke  Protection  Model  (VSPM)  (Johnson  and  Rouse,  1997)  was  developed 
as  an  augmentation  to  COMBIC  by  including  certain  higher  aspects  of  smoke  deployment  systems. 
VSPM  explicitly  models  dischargers  locations  and  orientation  on  vehicles  as  well  as  the  orientation 
of  the  vehicles  on  the  battlefield  to  compute  grenade  locations  for  input  into  the  COMBIC  model. 
Before,  COMBIC  users  would  have  to  manually  compute  the  location  of  grenade  detonations. 
These  locations  are  dependent  upon  the  location  and  orientation  of  the  firing  tubes  in  the  discharger, 
the  location  and  orientation  of  the  discharger  on  the  turret,  the  location  and  orientation  of  the  turret 


with  respect  to  the  hull,  and  the  location  and  orientation  of  the  hull  with  respect  to  the  battlefield.  In 
a  simulation  study,  where  an  analyst  might  want  to  simulate  the  performance  of  an  active  defense 
system,  the  subtleties  of  component  placement  could  be  important.  The  augmentation  improves  the 
fidelity  and  resolution  of  the  simulated  smoke  generation  process. 

3.2  MODTRAN 

MODTRAN  is  a  computer  program  that  calculates  the  radiance  and/or  transmission  for  a 
specified  path  through  the  atmosphere.  The  transmission  calculation  use  single  parameter  band 
models  to  compute  the  molecular  line  absorption  of  selected  atmospheric  species.  Molecular 
continuum  absorption,  molecular  scattering,  and  aerosol  absorption  and  scattering  are  also 
included.  The  radiance  calculations  consider  contributions  from  atmospheric  self-emission,  solar 
and/or  lunar  radiance  single  scattered  into  the  path,  direct  solar  irradiance  through  a  slant  path  to 
space  and  multiple  scattered  solar  radiance  into  path.  The  atmosphere  is  treated  as  a  stack  of  up 
to  33  atmospheric  layers.  Physical  parameters,  ranging  from  pressure  and  temperature  to 
molecular  absorption  and  extinction  coefficients  are  defined  for  each  layer.  As  the  path  passes 
through  each  layer  in  the  model,  the  atmospheric  components  of  interest  are  computed  and 
summed  over  the  path  and  wavelength  band.  Several  standard  atmospheres  are  provided  for  the 
user.  MODTRAN  is  used  to  correct  the  missile  plume  data  for  atmospheric  losses  that  occurred 
during  the  missile  test.  The  MODTRAN  is  used  in  conjunction  with  the  DAY24  Generator 
model  to  account  for  the  atmospheric  losses  for  the  user-defined  foreign  environments.  The 
DAY24  Generator  model  supplies  the  necessary  physical  parameters  for  the  atmospheric  layers 
traveled  by  the  LOS. 

3.3  FLYOUT  Model 

The  missile  FLYOUT  simulation  is  a  full  digital  fly-out  model  of  a  threat  antitank  guided  missile 
system  against  a  single  target  (Herold,  1998).  The  simulation  allows  a  user  to  input  target 
position  and  speed  along  with  missile  launcher  position.  The  missile  is  launched  when  the 
simulation  is  started.  During  the  engagement,  missile  and  target  data,  such  as  position  and 
velocity,  are  stored  on  disk.  At  the  end  of  the  engagement,  which  is  when  the  missile  strikes  or 
flies  past  the  target,  the  radial  and  x,  y,  z  miss  distance  is  recorded.  Target  and  missile  trajectory 
data  in  graphical  form  can  be  generated.  The  engagement  environment  can  be  benign  or  include 
countermeasures.  The  modeling  of  the  missile  beacon  and  countermeasure  does  not  include  glint 
or  reduction  in  intensity  by  obscurants.  Future  refinements  will  include  modeling  the  variation  in 
aspect  angle  of  the  missile  caused  by  windspeed  and  direction.  Future  work  will  alleviate  this 
problem. 

4.  Models  in  Development 
4.1  MSPROP 

The  MSPROP  model  is  the  heart  of  the  effort  to  propagate  the  missile  plume  signature  from 
missile  to  receiver.  MSPROP  will  modify  the  missile  plume  signature  based  upon  atmospheric 
losses  calculated  for  the  specific  location  the  user  has  chosen  for  engagement.  High  crosswinds 


can  increase  the  aspect  angle  of  the  missile.  The  missile  and  plume  will  then  be  viewed  at  a 
slight  angle  to  the  direction  of  flight.  MSPROP  will  not  initially  compute  the  effects  of  these 
wind- induced  changes  in  the  missile’s  aspect  angle  on  the  missile  plume  signature.  The  effort  for 
the  current  year  is  to  enable  MSPROP  to  work  for  a  single  threat  missile.  Future  work  will 
improve  the  model  to  address  wind-induced  effects  on  aspect  angle  and  the  effects  of  clutter. 
MSPROP  will  also  access  MODTRAN  to  determine  the  atmospheric  losses  for  the  LOSs  from 
the  tank  to  the  missile.  Atmospheric  profiles  will  be  developed  this  year  for  four  sites  of  interest. 
Effects  of  weather  will  be  included  in  fiscal  year  99. 

4.2.  Day24  Generator  Model 

The  purposes  of  the  Day24  model  is  to  take  the  (usually  sparse)  meteorological  data  obtained 
from  world-wide  climatological  data  bases  and  then  "fill  in"  missing  data  that  the  user  considers 
critical  for  their  specific  mission.  In  particular,  the  model  can  produce  a  best  estimate  of  a  full 
diurnal  weather  cycle  based  upon  what  data  is  available  (which  may  include  climatological 
studies  from  our  own  sources).  The  model  also  produces  vertical  profiles  of  parameters  such  as 
wind  speed,  temperature,  relative  humidity,  and  in  some  cases,  aerosol  concentrations.  The 
vertical  profiles  begin  at  the  (Earth)  surface  and  extend  as  high  as  the  mixing  level  that  can  vary 
from  as  low  as  about  100  meters  at  night  to  as  high  as  4000  meters  during  the  day.  A  byproduct 
of  the  model  is  sub-surface  temperatures  down  to  a  depth  of  approximately  1 -meter  into  the  soil. 
The  model  can  also  be  used  to  drive  optical  turbulence  and  electromagnetic  (em)  clutter  models 
as  affected  by  meteorological  variations.  The  model  is  semi-empirical  and  depends  upon  a  good 
set  of  input  for  most  accurate  results.  The  model  treats  only  time  scales  large  in  comparison  to 
turbulent  fluctuations  although  some  turbulent  parameters  may  be  estimated  from  the  output.  The 
model  is  two-dimensional  in  that  it  treats  time  dependence  and  vertical  variations  (but  not 
horizontal).  The  model  assumes  flat  terrain  in  the  immediate  vicinity  of  the  measurements  and 
predicts  only  for  the  point  of  the  measurements.  Plans  are  in  process  for  including  complex 
terrain  and  adverse  weather  in  future  versions. 

The  model  uses  it's  own  tailored  version  of  the  surface  energy  balance  for  time  evolution  and 
the  relatively  new  transient  turbulence  theory  of  transport  for  vertical  profiles.  The  central 


Figure  4  Sketch  demonstrating  the  surface  energy  balance  and  turbulent  reaction. 


In  the  sketch  of  Figure  4  the  various  fluxes  are  (a)  the  net  Radiative  component,  Rn,  from 
sun,  sky,  and  surface,  (b)  modeled  air  sub-surface  heat  flux  S,  and  (c)  the  eddy  heat  flux,  H, 
driven  by  the  wind  and  turbulent  exchange.  If  the  fluxes  balance  then  there  is  no  change  in 
surface  temperature,  otherwise  the  rate  of  change  is  governed  by  the  degree  of  the  imbalance. 
Further  details  of  the  mathematical  approach  can  be  found  in  Sutherland  et.  al,  1994.  An 
example  of  the  model  as  developed  thus  far  is  shown  in  Figure  5. 
a)  b) 


Figure  5a-d  Example  of  DAY24  model  showing  two  consecutive  24  hour  periods;  (a)  driving 
radiation  parameters,  (b)  air  and  subsurface  temperature  reactions,  (c)  instantaneous  surface 
fluxes,  and  (d)  cumulative  surface  fluxes. 

The  radiation  (and  wind)  are  the  main  drivers  of  the  model  and  are  shown  in  Figure  5a. 
The  values  here  were  made  up  for  illustration  to  simulate  the  case  of  a  fair  weather  day  with 
constant  windspeed  (not  shown)  followed  by  a  sharp  decrease  in  wind  at  midnight  and  later  an 
increase  near  midday.  The  radiation  is  comprised  of  the  solar  component  (based  upon  sun  angle 
and  atmospheric  attenuation)  and  the  sky  component  (which  is  most  influenced  by  cloud  cover). 
For  illustration  we  assumed  the  sky  component  to  be  constant  the  first  day  and  linearly 
decreasing  the  second  day.  The  solar  component  was  modeled  the  same  each  day.  The  reaction 
as  affecting  the  air  and  subsurface  temperatures  are  shown  in  Figure  5b.  Note  the  slow  decrease 
in  temperature  to  a  minimum  after  5  to  6  hours  followed  by  the  sharp  increase  as  the  solar 
component  increases,  and  the  subsequent  flux  changes  shown  in  Figure  5c. 

The  maximum  air  temperature  is  reached  after  15  hours  and  the  maximum  surface 
temperature  is  reached  after  14  hours.  Note  after  the  end  of  the  first  day  the  overall  increase  of 
about  2  degrees  for  both  the  air  and  surface  temperatures,  indicating  a  net  increase  in  input 


energy.  The  second  day  is  similar  to  the  first  except  that  the  sky  component  of  radiation  is 
allowed  to  decrease  at  a  constant  rate.  This  is  enough  to  return  the  final  air  and  surface 
temperature  to  their  original  values  of  16  and  14  degrees  respectively,  indicating  a  net  energy 
input  near  zero  for  the  two  day  period.  This  is  also  apparent  from  the  cumulative  fluxes  shown  in 
Figure  5d  which  shows  a  net  increase  of  about  1.16  watts/day  after  the  end  of  the  first  24  hour 
period  but  near  zero  after  the  full  two  day  cycle. 

Our  current  plans  call  for  further  work  on  the  model,  the  most  significant  being  the 
further  development  to  the  transilient  turbulence  algorithm  to  model  vertical  profiles  and  the 
mixing  height.  With  these  so  determined  then  other  electro-optical  parameters,  such  as  the  index 
of  refraction  structure  parameter,  C\ ,  optical  turbulence  can  be  estimated  using  techniques 

developed  in  Yee  et.  al.,  1993.  We  also  have  fieldwork  currently  underway  to  verify  the  model 
and  develop  methods  for  optimizing  with  best  fits  to  field  measurements. 

4.3  Laser  Propagation  Model 

The  Laser  Propagation  model  is  intended  as  a  tool  to  evaluate  laser-warning  receivers  and 
laser  designator  systems  as  affected  by  conventional  military  obscurants  such  as  fog  oil.  This 
computer-based  model  uses  ray  tracing  and  Monte  Carlo  techniques  similar  to  those  used  in 
BRLCAD  (Butler,  and  Tannebaum,  1998).  The  model  is  capable  of  providing  both  the  directly 
transmitted  radiation  and  multiple  scattering  from  all  directions  inside  an  obscurant  cloud.  The 
model  treats  the  obscurant  as  a  finite  array  of  small  volume  elements,  or  voxels,  assuming  the 
extinction  and  scattering  properties  to  be  know  from  first  principles  optical  models.  An  example 
of  the  scattering  properties  for  fog  oil  is  shown  in  Figure  6a. 

LASER  PROPAGATION  MODEL  LASER  PROPAGATION  MODEL 

PLOT  OF  PARTICLE  SIZE  MIECODE  RESULTS  FOR  FOGOIL 


Figure  6.  Plot  of  particle  size  distribution  (a)  and  corresponding  single  particle  optical  properties 
(b)  of  fog  oil  used  in  the  Laser  Propagation  Model. 


The  plots  in  Figure  6  were  generated  with  the  ARL  model  MIECODE  (Yee,  et.  al.)  which 
is  based  upon  the  Mie  theory  of  scattering  for  spherical  particles.  The  curves  on  the  left  show 
the  particle  number  density,  N(r),  particle  mass,  m(r),  and  geometrical  cross-section,  A(r),  as  a 


function  of  particle  size  (radius).  Note  the  peak  in  the  spectrum  at  about  r=0.187  microns,  which 
is  very  near  the  geometrical,  mean  radius,  which  is  0.215  microns  for  this  case.  The  results  here 
were  generated  assuming  a  log-normal  particle  size  distribution  of  width  0=1.45  which  is  typical 
of  measured  values  for  fog  oil.  The  plots  on  the  right  were  generated  with  the  MIECODE  model 
for  a  laser  wavelength  of  1.06  microns  and  show  the  optical  extinction  efficiency,  Qc ,  albedo, 
w0 ,  and  phase  function  asymmetry  parameter,  g,  as  a  function  of  particle  radius.  Note  the  general 

monotonic  increase  in  the  extinction  efficiency  at  small  values  of  r  and  the  leveling  off  to  a  value 
near  2  at  higher  r.  Note  also  the  fine  scale  "ripple"  characteristic  of  Mie  scattering  giving 
efficiencies  as  high  as  4.29  at  r=0.756. 

The  optical  extinction  efficiency  when  multiplied  by  the  geometrical  cross-section 
gives  what  is  conventionally  called  the  optical  extinction  cross-section  which  is  used  in  the  Laser 
Propagation  Model  uses  to  determine  a  probability  of  a  photon  interaction  in  the  Monte  Carlo 
routine.  If  the  interaction  does  occur  then  the  albedo  determines  the  probability  of  either 
scattering  or  absorption.  If  the  photon  is  scattered,  then  the  angle  of  scattering  is  determined  by 
the  phase  function  asymmetiy  parameter  using  the  Henyey-Greenstein  formulation.  These 
probability  rules  are  used  in  a  ray-tracing  algorithm  employing  several  thousands  of  photon 
trajectories  to  arrive  at  the  total  reaching  a  given  point.  The  model  is  also  time  dependent  and  can 
address  pulse  stretching  as  well  as  directional  scattering.  This  year  the  effort  is  focused  on 
creating  a  model  that  can  propagate  energy  through  a  simple  fogoil  smoke  cloud.  Next  year  the 
effort  will  be  focused  on  extending  this  capability  to  other  obscurants,  integration  with 
atmospheric  aerosols  (i.e.  rain,  haze,  dust)  and  using  scaling  techniques  to  reduce  the  size  of  the 
data  base  this  model  creates. 

5.  Scenarios 

Appropriate  met  observation  data  will  be  collected  for  four  sites  and  categorized 
according  to  adverse  effects  on  dominant  EM  and  other  sensor  systems.  Miniature  smoke 
vignettes  will  be  created  for  the  four  chosen  sites  representing  both  friendly  and  foreign  smokes 
(where  appropriate).  MSPROP  will  be  run  for  the  prevalent  met  conditions  at  the  four  sites  and 
for  the  established  smoke  in  the  smoke  vignettes.  Self-defense  smokes  like  the  M76  IR  grenades 
and  L8A1  grenades  will  then  be  “played”.  MSPROP  will  then  be  run  again  to  determine  if  these 
self-defensive  smoke  grenades  will  interfere  with  the  MWR  ability  to  track  the  missile  plume. 

A  scenario  consisting  of  only  vehicle  dust  will  also  be  developed.  A  series  of  both  threat  based 
and  survivability  suite  sensor  predictions  will  be  developed  based  on  that  data. 

6.  Summary 


The  TTM  effort  entitled  “Atmospheric  Effects  for  Ground  System  Hit  Avoidance”  will  be  a 
useful  tool  that  in  conjunction  with  simulation  or  software  algorithms  of  MWR  and  LWR  can 
provide  a  useful  tool  in  measuring  atmospheric  and  obscurants  effects  on  the  warning  receivers. 
These  effects  in  turn  can  affect  the  Commander’s  Decision  Aids.  The  total  package,  integrating 
meteorological  and  systems  effects,  will  offer  higher  fidelity  alternatives  for  current  simulations 
available  to  the  systems  analysis  community. 


So  ( 


7.  References 


Anderson,  L.,  Roger  Holmack,  Thelma  Chenault,  and  Joseph  Churchman,  1998,  “Making 
Obscurant  Analysis  Productive”,  Proceedings  of  the  1998  Smoke  Obscurant  Symposium, 
Edgewood  at  Aberdeen  Proving  Ground,  MD  (In  Press). 

Ayres,  S.D.,  and  S.  DeSutter,  1993,  “Combined  Obscuration  Model  for  Battlefield  Induced 
Contaminants  (COMBIC)  Users  Guide”,  U.S.  Army  Research  Laboratory. 

Butler,  L.A.,  P.J.  Tannebaum,  1998,  Private  Communication,  U.S.  Army  Research  Laboratory, 
Survivability  Lethality  Analysis  Directorate. 

Cundiff,  C.R.,  1998,  Private  Communication,  U.S.  Army  Research  Laboratory,  Survivability 
Lethality  Analysis  Directorate. 

Herold,  C.  R.,  1998,  Private  Communication,  U.S.  Army  Research  Laboratory,  Survivability 
Lethality  Analysis  Directorate. 

Johnson,  D.J.  and  W.G.  Rouse,  1997,  “The  Vehicle  Smoke  Protection  Model  and  Cloud  Density 
Visualization  Utility”,  OMI-598,  Optimetrics,  Inc.,  Forest  Hill,  MD. 

Sutherland,  R.A.,  Yee,  Y.P.,  and  RJ.  Szymber,  1994,  "Transient  Turbulence,  Radiative  Transfer, 
and  Owning  the  Weather",  Proceedings  of  the  19945  Battlefield  Atmospherics  Conference, 

White  Sands  Missile  Range,  NM. 

Yee,  Y.P.,  Sutherland,  R.A.,  Rachele,  H.  and  A.  Tunick,  1993,  "Effects  of  Aerosol-Induced 
Radiative  Interactions  on  Stability  and  Optical  turbulence",  Proceedings  of  the  Society  of  Photo- 
Optical  Instrumentation  Engineers. 

Sutherland,  R.A.  and  W.M.  Farmer,  1996,  "Second  Workshop  on  the  Electromagnetic  of  Combat 
Induced  Atmospheric  Obscurants",  ARL-TR-832. 


t5cO. 


Target-to-Sensor  Vision 
(Problems,  Models,  and  Analyses) 

Robert  E.  Turner 
Obscurants 

Abstract:  For  all  applications  of  electro-optical  sensors  in  the  modem  battlespace  arena  it  is 
necessary  to  consider  and  account  for  the  presence  of  the  obscuring  effects  of  the  atmosphere 
between  the  target  and  the  sensor.  We  provide  a  brief  review  of  the  problems  associated  with 
atmospheric  conditions  when  obscurants  such  as  smoke,  dust,  haze,  fog,  and  precipitation  are  present, 
and  some  of  the  models  and  analyses  that  are  used  to  deal  with  these  problems.  Various  sensors 
(ultraviolet,  visible,  near  infrared,  and  thermal  infrared)  present  different  sets  of  concerns  because  of 
the  varying  wavelength  properties  of  the  attenuation  of  radiation  as  it  propagates  through  the 
atmosphere.  For  certain  sensors  such  as  those  that  operate  in  the  thermal  infrared  the  line-of-sight 
(LOS)  transmission  from  the  target  to  the  sensor  is  most  important,  whereas  for  other  sensors, 
primarily  those  in  the  UV,  visible,  and  near-infrared  region,  the  scattering  of  radiation  into  the  LOS 
also  needs  to  be  considered.  Many  models  have  been  developed  to  account  for  the  attenuation  of  the 
radiation  but  there  remains  the  problem  of  providing  sufficient  data  in  the  models  with  near  real-time 
data  acquisition  for  the  specific  geographic  region  of  interest.  Thus,  the  models  may  work  well  in  the 
abstract  but  not  well  for  the  area  and  time  of  application.  We  address  these  issues  to  determine  what 
can  be  done  to  produce  a  more  comprehensive  database  for  the  optical  and  thermal  properties  of  the 
obscurants  for  regional  applications  anywhere  in  the  world. 


1.0  Introduction 

In  the  modern  battlespace  arena  weather  plays  a  role  not  only  in  the  effect  that  it  has  on  the 
mobility  of  personnel  and  equipment  and  general  operations  but  also  in  the  overall  performance  of 
sensor  systems  that  are  needed  for  viewing  the  scene  and  for  target  acquisition.  Thus,  although 
meteorological  data  may  indicate  relatively  benign  conditions  for  the  transport  of  personnel  and 
equipment,  the  so-called  “optical  weather”  may  preclude  operations  because  of  atmospheric 
obscurants  that  exist  between  the  scene  and  the  sensor.  It  is  often  the  detailed  characterization  of  the 
optical  weather  that  is  important  as  to  whether  or  not  a  target  can  be  detected,  recognized,  or  be 
identified.  For  an  idealistic  situation  in  which  no  atmospheric  obscurants  are  present  and  the  line  of 
sight  (LOS)  between  the  target  and  sensor  contains  no  solid  or  liquid  matter,  the  only  interference 
with  the  transfer  of  radiation  arises  as  a  result  of  refraction,  scattering,  and  absorption  by  the 
atmospheric  gases.  Turbulence,  resulting  from  thermal  motion  in  the  atmosphere  can  either  distort 
an  image  or  alter  the  LOS  beam  of  radiation  as  in  the  case  of  the  use  of  a  laser  to  designate  a  target. 
In  addition,  certain  atmospheric  gaseous  (natural  and  anthropogenic)  components  can  selectively 
absorb  radiation  in  particular  spectral  regions  as  well  as  scatter  radiation  into  and  out  of  the  LOS. 
These  attributes  associated  with  the  gaseous  component  alone  can  have  an  adverse  effect  on  the 
ability  of  a  sensor  to  acquire,  detect,  recognize,  classify,  or  identify  targets.  This  effect  is,  however, 
even  worse  in  the  presence  of  aerosols  and  hydrometeors  (rain,  snow,  hail,  etc.).  These  obscurants, 
characterized  by  haze,  fog,  water  and  ice  clouds,  smoke,  dust,  and  precipitation  can  result  from 
natural  weather  systems  or  from  deliberate  action,  the  latter  usually  being  the  case  as  a 
countermeasure  by  opposing  forces.  The  enormous  variability  in  the  ability  to  “see”  a  target  depends 
upon  a  number  of  factors,  such  as  the  density  of  the  obscurant,  the  size  distribution  of  the  particles, 
their  composition,  and  to  some  extent  the  shape  of  the  individual  particles.  In  the  case  of  gases,  the 
type,  density  and  temperature  can  be  important.  As  a  result  of  the  variation  in  the  overall 
composition  of  the  atmosphere  between  the  target  and  sensor,  the  visibility  can  vary  from 
approximately  330  kilometers  for  an  ideal  atmosphere  with  no  particulate  matter  to  zero  for  an 
extremely  dense  cloud  of  smoke  or  dust,  even  for  short  path  lengths.  The  latter  is  clearly  evident  to 
anyone  who  has  been  in  smoke-filled  area. 

To  account  for  the  detailed  properties  of  the  atmospheric  obscurants  along  the  LOS  is  a 
major  problem.  In  a  scientific  field  experiment  it  is  usually  difficult  to  perform  many  of  the 
measurements  that  are  necessary  to  characterize  the  microphysical  properties  of  these  atmospheric 
particles  and  gases.  In  an  actual  military  engagement  it  is  clearly  not  feasible  to  perform  more  than  a 
few,  quick,  simple  measurements  at  best  or  to  make  estimates  to  ascertain  the  conditions  that  define 
the  LOS  obscurants,  in  addition,  it  is  sometimes  required  that  whatever  measurements  are  made,  that 
they  be  done  in  a  passive  rather  than  active  mode.  Thus,  these  requirements  can  place  severe 
restrictions  on  the  capability  of  any  system,  human  or  otherwise,  to  determine  reasonably  accurate 
values  for  the  parameters  associated  with  the  obscurant  matter.  Another  factor  to  consider  is  time. 
Wind  and  other  normal  weather  effects  can  quickly  alter  the  behavior  of  the  medium,  thereby 
changing  the  LOS  visibility  from  one  that  is  a  clear  condition  to  one  that  has  nearly  zero  visibility 
within  seconds.  All  these  attributes,  the  natural  weather  the  deliberate  action  on  the  part  of  opposing 
forces  in  the  use  of  countermeasures,  and  the  inadvertent  disturbing  effects  of  the  engagement 
process  itself  need  to  be  considered  in  the  development  of  models,  sensors,  and  systems  that  will  be 
used  for  military  operations.  Failure  to  account  for  the  atmosphere  obscurants  properly  could  have  a 
distinctly  negative  outcome  on  a  particular  military  action.  It  should  be  noted,  however,  that  the 
optical  weather  can  be  beneficial  if  one  has  detailed  information  on  the  particulate  and  gaseous 
components  and  the  quantities  on  which  they  depend.  If  one  force  has  greater  knowledge  of  the 


weather  conditions  than  the  other,  then  one  may  be  better  able  to  account  for  the  deleterious  effects 
on  sensor  performance  or  be  able  to  deploy  additional  sensors  or  countermeasure  systems  to  defeat 
the  action  of  the  opposing  force.  Regardless  of  the  situation  it  will  certainly  be  beneficial  to  have 
accurate  operational  models,  sensors,  or  systems  in  the  ever-increasingly  technological  battlespace  of 
the  future. 
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2.1  Sensor  spectral  ranges 

From  the  earliest  times  the  simplest  of  all  sensors  has  been  the  human  eye.  It  is  still  a 
remarkable  sensor  with  an  ability  to  perceive  the  energy  of  one  quantum  of  light  for  a  dark-adapted 
eye  with  a  range  of  illumination  of  10.  Other  sensors  have  been  developed  that  use  the  ultraviolet 
and  the  infrared  portions  of  the  electromagnetic  spectrum.  Table  1  indicates  the  general  ranges  of 
the  spectrum  for  radiation  from  the  ultraviolet  to  the  infrared.  Historically,  because  of  the 
atmospheric  “windows”  that  fall  in  the  visible  and  certain  parts  of  the  infrared  (3.0  pm  -  5.0  pm  and 
8.0  pm  -  12.0  pm),  these  regions  were  exploited  for  military  sensors.  They  represent  passive  sensors 
that  merely 
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Table  1.  Designations  of  the  spectral  ranges  for  electromagnetic  radiation  from  the  ultraviolet  to  the 
infrared. 

detect  radiation  or  scanners  and  imagers  for  the  display  of  a  scene.  More  recently,  sensors  are  being 
used  for  certain  regions  in  the  ultraviolet  part  of  the  spectrum.  It  must  be  realized  that  these  systems 
are  not  only  used  by  ground  troops  but  also  by  aircraft  personnel  and  by  spacecraft  for  surveillance. 
Nevertheless,  in  all  cases  one  must  take  into  consideration  the  propagation  of  the  radiation  from  the 
target  or  source  through  the  intervening  atmosphere  to  the  sensor.  Many  scenarios  can  be  imagined, 
such  as  the  use  of  a  laser  designator  to  illuminate  a  target,  the  viewing  of  troops  at  night  with  a  FLIR, 
attempting  to  see  targets  through  dust  clouds,  or  the  surveillance  of  militarily  significant  areas 
through  atmospheric  haze  with  satellite  sensors.  For  each  situation  the  radiation  that  propagates 


from  the  target  to  the  sensor  will  be  refracted  and  attenuated  by  the  atmosphere,  the  amount  of 
which  is  determined  by  the  type  and  concentration  of  gases  and  obscurants  such  as  aerosols  and 
precipitation  that  exist  in  the  region. 


2.2  Radiative  Processes 

To  understand  the  problem  associated  with  sensors  detecting  radiation  through  some 
obscuring  medium  such  as  dust  or  smoke  one  must  consider  all  components  of  the  radiation  that  enter 
the  aperture  of  the  sensor.  Figure  1  illustrates  the  basic  processes  that  occur  as  radiation  enters  the 
sensor.  Component  1  represents  the  direct  radiation  that  suffers  no  loss.  Loss  of  radiation  is 
represented  by  component  2  which  is  indicative  of  radiation  that  is  totally  absorbed  by  the  medium, 
and  by  component  3  which  represents  radiation  that  is  scattered  out  of  the  instantaneous  field  of 
view.  Gain  of  radiation  is  indicated  by  component  4  in  which  radiation  that  originally  propagates  in  a 
direction  outside  the  field  of  view  is  scattered  by  the  medium  into  the  field  of  view.  Finally, 
component  5  represents  radiation  that  is  either  emitted  by  fluorescence  or  by  thermal  emission  into 
the  field  of  view. 


Fig.  1.  Illustration  of  radiometric  processes  in  a  scattering,  absorbing,  emitting  medium 


The  radiometric  quantity  that  is  used  to  describe  the  radiation  that  is  transferred  from  a 
source  (e.g.,  the  Sun,  Moon,  target,  or  background)  through  some  medium  to  the  aperture  of  a  sensor 
is  called  the  radiance,  i.e.,  the  power  density  in  a  specific  direction  per  unit  solid  angle  for  a  particular 
wavelength  or  spectral  band.  The  radiation  that  enters  the  sensor  can  then  be  represented  by  the 
following  simple  equation: 

L  =  L0T  +  P,  (1) 

where  L0  is  the  radiance  reflected  or  emitted  by  the  target  into  the  field  of  view  and  T  is  the  LOS 
transmittance  that  attenuates  this  radiation  by  absorption  and/or  the  scattering  of  radiation  out  of 
the  field  of  view  as  represented  by  components  2  and  3  above.  The  last  term,  and  usually  the  one 
which  is  the  most  difficult  to  account  for,  is  the  one  that  represents  radiation  scattering  into  the  field 
of  view  and/or  radiation  that  is  emitted  along  the  field  of  view  as  indicated  by  components  4  and  5 
above.  It  is  referred  to  as  the  path  radiance  and  represents  the  multiple  scattering  of  radiation  as  well 
as  thermal  emission.  It  has  an  important  role  to  play  in  the  development  of  models,  especially  for 
sensors  that  operate  in  the  visible  and  near  infrared.  It  must  be  noted  that  the  contrast  between  a 
target  and  a  background,  represented  by  the  simple  equation 

c=  L±b 

Lb  (2) 

where  Lt  is  the  radiance  from  the  target  and  Lb  is  the  radiance  from  the  background,  can  also  be 
written  as 

C  =  C0Tc,  (3) 

where  C0  is  the  inherent  target-background  contrast  at  the  target  position  and  T~  is  the  contrast 
transmittance.  In  general,  the  contrast  transmittance  can  be  written  as 

Tc  =  UoT,  (4) 

Lb 

where  T  is  the  usual  LOS  beam  transmittance.  Although  this  is  a  simple-looking  equation,  the 
calculation  of  the  radiances  usually  involves  solving  a  complicated  equation  of  radiative  transfer  using 
correspondingly  large  and  complicated  computer  codes.  This  is  especially  true  if  the  geometry  of  the 
medium  is  complex  as  in  the  case  of  smoke,  dust,  fogs,  or  natural  clouds.  The  important  point  is  that 
if  no  scattering  takes  place  and  if  we  are  dealing  with  the  spectral  region  where  thermal  emission  is 
insignificant,  then  the  contrast  transmittance  is  unity  and  there  is  no  change  in  the  contrast!  Thus, 
even  for  a  strongly  absorbing  dust  or  smoke  cloud  the  contrast  remains  the  same  as  the  inherent 
contrast  if  no  scattering  occurs.  Unfortunately,  for  all  interactions  between  radiation  and  matter 
some  scattering  must  necessarily  occur  even  if  it  manifests  itself  as  diffraction.  In  the  thermal 
infrared  such  as  the  3-5  um  or  the  8-12  um  regions  an  image  is  similar  to  a  visible  one  of  high 
illumination  but  of  low  contrast.  Whatever  background  noise  exists, 


it  is  essentially  independent  of  the  signal  and  can  easily  be  accounted  for  by  subtraction  as  in  a  FLIR. 
Such  is  not  the  case  for  the  visible  or  the  reflective  infrared  and  the  background  noise  does  depend 
upon  the  signal  level.  Thus,  we  have  the  complicating  effects  of  path  radiance  and  sky  radiance. 

3.0  The  Obscurants 
3.1  Basic  Properties 

The  particulate  obscurants  in  the  atmosphere  can  be  represented  by  their  size,  shape,  and 
composition.  Table  2  indicates  the  basic  physical  properties  of  these  particles: 
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Table  2.  Characteristics  of  atmospheric  obscurants 


In  table  2  the  quantity  N  is  the  concentration  of  the  particles.  One  should  note  that  there  can 
be  a  large  difference  in  the  chemical  or  mineralogical  composition  of  the  natural  aerosol  as  well  as 
for  dust  and  smoke  particles.  Many  natural  aerosols  are  composed  of  materials  such  as  ammonium 
sulfate,  quartz,  hematite,  silicate,  and  soot.  Smoke  can  be  generated  inadvertently  or  by  deliberate 
action  as  in  the  1991  Gulf  war.  In  that  case  the  smoke  plumes  were  a  combination  of  soot  (black)  and 
salts  (white)  with  various  mixtures  [1,2].  In  the  battlefield,  smoke  can  arise  from  any  source  such  as 
burning  vehicles,  buildings,  vegetation,  or  it  can  arise  from  deliberate  deployment  of  smoke  bombs 
and  generators.  Furthermore,  the  composition  varies  with  geographic  location,  time  of  day,  and 
season.  For  Naval  applications,  the  natural  aerosol  has  essentially  three  components,  each 
component  of  which  is  a  fimction  of  an  environmental  parameter  such  as  the  current  or  average 
wind  speed.  As  the  wind  is  primarily  responsible  for  the  generation  of  the  aerosol  over  the  ocean, 
the  larger  particles  are  mainly  composed  of  water  droplets.  It  should  also  be  noted  that  smoke  must 
be  considered  for  naval  engagements  as  well,  for  example  in  the  burning  of  ships  or  aircraft  and  in  the 
littoral  regions  where  nearby  continental  sources  exist.  Dust  is  also  an  important  obscurant.  In  the 
arid  region  in  the  middle  Bast  it  was  mixed  with  the  smoke  in  the  burning  of  the  Kuwati  oil  wells.  It 
can  also  be  generated  by  the  movement  of  troops  and  materiel,  especially  when  wind  is  present. 
Finally,  fog  and  precipitation  can  occur 

and  these  particles  can  intermingle  with  the  dust,  smoke,  and  the  natural  particles  to  create  a 
complex  mixture  of  aerosols  that  can  seriously  reduce  the  visibility,  contrast,  and  transmittance  in 
the  atmosphere. 

It  must  be  realized  that  it  is  not  necessarily  the  total  amount  of  material  along  the  LOS  but, 
rather,  how  that  material  is  distributed  that  determines  factors  such  as  the  LOS  transmission  or  the 
visibility.  This  can  be  illustrated  with  the  following  simple  example  of  viewing  a  target  along  a 
horizontal  path  100  meters  in  length.  One  should  note  that 
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Table  3.  Comparison  of  the  optical  (visible  region)  properties  of  a  heavy  rain  and  a  fog  for  a  path 

length  of  100  meters. 


although  the  total  water  mass  along  the  path  in  the  heavy  rain  is  almost  6  times  greater  than  that  of 
a  fog,  the  LOS  transmission  and  the  visibility  are  much  less  in  a  fog.  This  clearly  indicates  the 
significance  of  the  microphysical  parameters  for  aerosols. 

3.2  Key  (microphysical)  parameters 


What  are  the  key  parameters  that  distinguish  one  atmospheric  obscurant  from  another?  As 
indicted  in  the  previous  section,  the  distribution  of  particle  size  and  composition  account  for  some  of 
the  differences.  However,  for  practical  applications  to  military  systems  there  are  usually  two  levels 
of  parameters  that  need  to  be  considered.  First,  there  are  the  basic  or  primary  parameters  such  as,  the 
size  distribution  of  the  particles,  the  complex  index  of  refraction,  the  shape  of  the  particles,  and  the 
number  or  mass  density  of  a  collection.  These  quantities  are,  in  turn,  dependent  upon  weather  related 
quantities  such  as  the  relative  humidity  and  the  wind  speed,  as  well  as  the  height  above  the  surface. 
Thus,  for  aerosols 

Size  distribution  =  F  (relative  humidity,  wind  speed,  altitude) 

Refractive  index  =  F  (relative  humidity,  wind  speed,  altitude,  wavelength) 

Refractive  index  =  F  (relative  humidity,  wind  speed,  altitude,  wavelength) 

Reasonably  good  models  now  exist  which  can  determine  the  functional  behavior  in  terms  of  these 
weather  and  geometric  parameters.  For  Naval  applications,  the  natural  aerosol  has  essentially  three 
components,  a  small  particle  component  with  an  average  (mode) components,  a  small  particle 
component  with  an  average  (mode)  radius  of  0.03  |nm,  an  intermediate  sized  component  with  a  mode 
radius  of  0.24|im,  and  a  large  particle  component  with  a  mode  radius  of  2.0  |um.  This  is  illustrated  in 
Fig.  2. 
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Fig.  2.  Navy  3-component  aerosol  model  [3] 

The  dependence  of  the  shape  factor,  however,  is  far  more  difficult  to  determine  although  there  are 
now  computer  codes  [4],  which  can  be  used  for  particles  of  various  shapes.  Second,  there  are 
quantities  that  are  to  be  measured  or  calculated  as  a  result  of  knowing  the  values  of  the  primary 
quantities.  These  are:  the  scattering,  absorption,  and  extinction  (scattering  +  absorption)  cross 
sections,  the  corresponding  attenuation  coefficients,  and  the  scattering  phase  function,  a  quantity 
that  describes  the  directional  properties  of  the  radiation  that  is  scattered  from  a  particle.  An 
important  quantity,  the  single-scattering  albedo,  is  the  ratio  of  the  scattering  coefficient  to  the 
extinction  coefficient  and  essentially  determines  how  much  absorption  occurs  as  opposed  t(; 
scattering.  It  also  has  an  important  bearing  on  the  contrast.  Thus,  one  can  write  these  secondary 
quantities  as 
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a  (absorption  coeff.)  =  F  (size  distr.,  refr.  index,  wavelength,  no.  density,  shape) 

(3  (scattering  coeff.)  =  F  (size  distr.,  refr.  index,  wavelength,  no.  density,  shape) 

K  (extinction  coeff.)  =  F  (size  distr.,  refr.  index,  wavelength,  no.  density,  shape) 

0Jo  (albedo)  =  ~ lie  =  F  (size  distr.,  refr.  index,  wavelength,  shape) 
p  (scattering  phase  function)  =  F  (size  distr.,  refr.  index,  wavelength,  shape,  angle 

It  is  significant  that  a  particle  with  a  cross-sectional  area  that  is  almost  three  times  that  of  another 
does  not  necessarily  have  a  cross  section  that  is  three  times  greater.  A  number  of  examples  of  this 
are  given  by  Kerker  [5]  for  particles  with  several  indices  of  refraction.  In  Fig.  3  we  illustrate  this  for 
radiation  with  a  wavelength  of  550  nm  incident  on  a  non-absorbing  particle  with  an  index  of  1.33 
and  a  radius  1  |lm,  in  which  the  actual  cross  section  is  only  -24%  greater  than  that  of  a  particle  with 
a  radius  of  0.57  |xm.  The  efficiency  factor  is  the  actual  cross  section  divided  by  the  geometric  cross 
section.  This  indicates  the  importance  of  the  complex  index  of  refraction.  For  a  strongly  absorbing 
particle,  such  as  the  one  with  an  index  of  1.33-  0.4i,  the  particle  of  radius  1  ~m  has  a  cross  section 
that  is  about  three  times  that  of  the  particle  with  a  radius  of  0.57  pm.  The  sphere  with  an  index  of 
1.33-1  .5i  is  not  considered  to  be  an  absorbing  particle  although  the  imaginary  part  is  large.  The 
radiation  cannot  penetrate  the  sphere  and  it  is  reflective. 


Fig.  3.  Extinction  efficiency  factors  for  spheres  with  various  indices  of  refraction 


All  of  these  quantities  are,  of  course,  implicitly  functions  of  the  variables  on  which  the 
primary  quantities  depend,  such  as  relative  humidity  and  wind  speed.  The  Air  Force  at  Phillips 
Laboratory  [6]  has  performed  extensive  computations  on  these  quantities  for  use  in  atmospheric 
transmission  codes.  Figure  4  illustrates  their  calculation  of  the  three  attenuation  coefficients  for  a 
size  distribution  characteristic  of  a  rural  atmosphere  with  a  relative  humidity  of  50  %. 


Fig.  4.  Attenuation  coefficients  vs.  wavelength  for  the  rural  aerosol  model  at  50%  relative  humidity. 
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The  dependence  of  the  volume  extinction  coefficient  on  the  relative  humidity  is  also 
displayed  in  Fig.  5.  Likewise,  Fig.  6  illustrates  the  single-scattering  albedo  for  the  same 
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Fig.  5.  Extinction  coefficients  vs.  wavelength  for  the  rural  aerosol  model  for  different 
relative  humidities  and  constant  number  density  of  particles. 
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Fig.  6.  Single  scattering  albedo  for  the  rural  aerosol  model  for  different  relative  humidities. 
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atmosphere  and  Fig.  7  depicts  the  scattering  phase  function  for  a  boundary  layer  aerosol  at 
wavelength  of  1.06  micrometers  for  four  different  atmospheres.  It  is  important  to 


Fig.7.  Angular  scattering  functions  of  low  altitude  aerosol  models  at  1.06  |im. 
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note  that  there  is  a  strong  dependence  on  the  composition  with  the  rural  atmosphere  being  a  mixture 
of  water  soluble  and  dust-like  aerosols.  The  importance  of  the  phase  function  is  clearly  indicated. 

The  amount  of  scattered  energy  changes  by  at  least  a  factor  of  1000’  over  the  range  from  00 
(forward  scattering)  to  1800  (backward  scattering).  For  clouds  and  fogs  it  can  change  by  even  larger 
amounts.  In  general,  if  the  imaginary  part  of  the  index  of  refraction  is  large  (0.2)  the  amount  of 
absorption  will  be  large,  unless  it  is  excessive(e.g.  -10.0)  in  which  case  the  particle  becomes  reflective 
and  no  longer  absorbs  the  incident  radiation.  Therefore,  the  single-scattering  albedo  is  a  strong 
determinant  of  the  amount  of  absorption.  If  05o  =  0  there  is  no  scattering  whereas  if  03o  =  1  there  is 
no  absorption. 

With  the  volume  attenuation  coefficients  one  can  then  compute  or  measure  the 
dimensionless  parameter,  optical  depth.  It  is  the  attenuation  coefficient  integrated  over  the  path  of 
interest  and  is  a  function  of  all  the  parameters  on  which  the  attenuation  coefficients  depend,  as  well 
as  the  path  length.  This  parameter  plays  a  critical  role  in  the  radiative-transfer  codes. 

Finally,  a  quantity  of  considerable  importance  that  can  be  computed  directly  from  the 
volume  extinction  coefficient  is  the  visual  range,  defined  as  that  distance  for  which  an  observer  views 
a  target-background  contrast.  It  is  given  by  the  formula 
V  3.912 

K  (5) 

where  k  is  the  volume  extinction  coefficient  at  the  Earth’s  surface  at  a  wavelength  of  555  nrn,  This 
is  the  formula  for  daytime  visibility  with  a  contrast  of  2%. 


4.0  System  (operational)  Parameters 

The  final,  or  system-dependent  parameters  are  those  that  are  used  in  an  operational  sense.  Having 
measured  or  computed  the  secondary  parameters  in  Section  3.2  one  can  then  use  a  higher  level  model 
to  compute  the  radiometric  quantities  that  are  useful  for  actual  operational  situations.  Examples  of 
these  models  are  LOWTRAN  and  MODTRAN,  computer  programs  developed  by  the  Air  Force  [7] 
which  are  used  to  compute  the  LOS  transmittance  and  the  radiance  in  any  spectral  band  from  ~  0.20 
pm  to  300  pm  for  their  “standard”  atmospheres  as  well  as  for  a  user-defined  atmosphere.  Figure  8 
illustrates  a  representative  output  of  LOWTRAN.  Here  one  can  clearly  see  the  “window”  regions  of 
the  natural  atmosphere.  Thus,  sensors  are  designed  to  operate  in  the  visible,  1.06  pm,  3  -  5  pm,  and  8 
-12  pm  regions  where  the  transmittance  is  high.  It  should  be  noted,  however,  that  other  obscurants 
such  as  dust  and  smoke  may  affect  the  performance  of  sensors  in  these  spectral  regions.  An  example 
of  the  computation  of  radiance  in  the  3  to  5  pm  band  as  a  function  of  visibility  is  depicted  in  Fig.  9. 
The  Army  [8],  in  connection  with  the  BOSAEL  (Electro-Optical  Systems  Atmospheric  Effects 
Library)  program  during  the  1980’s  produced  many  practical  models  for  the  calculation  of 
radiometric  quantities  for  a  large  variety  of  sensors  and  battlefield  conditions.  In  addition,  the  Air 
Force  developed  an  Electro-Optical  Tactical  Decision  Aid  (EOTDA)  [9]  model  now  being  used  by  the 
Navy  and  the  Army  as  well.  Most  of  these  "system-level”  models  will  allow  a  user  to  input  specific 
meteorological  conditions  in  terms  of  weather  data,  as  well  as  sensors,  targets,  and  backgrounds. 
These  models  then  take  into  consideration  the  algorithms  and  data  from  the  secondary  models  and/or 
data  and  compute  the  radiometric  components  for  multiply-scattered  radiation  in  the  presence  of 


any  obscurant  material.  Thus,  at  some 


Fig.  8.  Atmospheric  transmittance  for  a  1  km  path  at  sea  level  for  six  model  atmospheres 

intermediate  stage  in  these  high-level  models  the  functional  dependencies  may  be: 

Transmittance  =  F  (Met.  Data,  geometry,  wavelength,  operations) 

Radiance  =  F  (Met.  Data,  geometry,  wavelength,  targets  &  bkgds.,  operations) 

Contrast  =  F  (Met.  Data,  geometry,  wavelength,  targets  &  bkgds.,  operations) 

where  by  operations  is  meant  those  actions  that  can  affect  the  nature  of  the  obscurants,  such 
vehicular  motion  or  live  fire. 


Fig.  9.  Radiance  components  in  the  3-5  |im  wavelength  band  according  to  LOWTRAN.  Observer 
altitude  =  1  km,  target  altitude  =  0  km,  solar  zenith  angle  =  45°,  relative  azimuth  angle  =  0°,  observer 
zenith  angle  =  93°,  99°  105°.  Midlatitude  summer,  tropospheric  model.  Ground  temperature  =295  K 
and  the  emissivity  =0.9 


Finally,  the  functional  dependency  of  the  operational  models  can  be  indicated  as  follows: 
LOS  visibility  =  F  (Met.  Data,  operations) 

Minimum  Detectable  Temp.  =  F  (Transmittance,  Radiance) 

Minimum  Resolvable  Temp.  =  F  (Transmittance,  Radiance) 

Lock-on-range  =  F  (Transmittance,  Radiance) 

5.0  Model  Uncertainties 


Where  do  the  greatest  uncertainties  lie  in  both  the  models  and  in  the  measurement  of  the  key 
parameters  for  an  “complete"  operational  system-level  model?  Let  us  consider  four  levels  of  systems 
as  are  illustrated  in  Fig.  10.  It  must  be  realized  that  insofar  as  atmospheric  obscurants  are  concerned, 
there  will  be  certain  tradeoff  factors  to  be  considered  in  the  determination  of  those  parameters  for 
which  critical  decisions  need  to  be  made.  In  the  Research  Model  1  there  is  a  completely  controlled 
condition  in  which  one  can  specify  the  particle  size,  composition,  and  environmental  parameters. 
There  is  a  high  degree  of  knowledge  of  the  parameters  in  this  limited  system  but  there  is  a  lack  of 
versatility  in  the  representation  of  a  realistic  environment.  In  a  field  experiment  as  in  the  Research 
Model  2  there  is  some  control  of  conditions  (e.g.,  selection  of  time  of  day  or  location)  and  some 
knowledge  of  the  data  as  obtained  from  the  measurements.  Also,  there  is  now  a  more  realistic 
environmental  condition  with  the  uncertainties  associated  with  the  natural  weather.  In  the 
Operational  Model  1  there  is  a  passive  military  environment  (e.g.,  surveillance)  with  little  or  no 
control  over  the  conditions,  limited  knowledge  of  the  system  parameters  and  perhaps  a  time 
constraint.  Nevertheless,  this  does  represent  a  much  more  realistic  environment.  Finally,  one  has  in 
the  Operational  Model  2  a  truly  realistic  situation  of  engaged  forces  with  no  control  over  the 
environmental  system  parameters  and  very  little  knowledge  of  the  actual  atmospheric  conditions  in  a 
rapidly  changing  environment.  In  Table  4  we  see  an  assessment  of  the  level  of  knowledge  and 
importance  of  the  value  of  the  input  parameters  for  the  model  output.  It  must  be  kept  in  mind  that 
this  is  for  controlled  laboratory  conditions  in  which  the  investigator  has  many  first-principle,  well- 
documented  models  and  measurement  apparatus  for  making  detailed  experiments  on  the  aerosol.  One 
can  see  that  knowing  the  particle  size  distribution  and  the  index  of  refraction  is  of  critical 
importance  insofar  as  the  production  of  accurate  values  of  the  output  quantities  is  concerned. 
Although  models  do  exist  for  the  computation  of  the  output  quantities  for  irregularly-shaped, 
inhomogeneous  particles,  it  is  usually  very  difficult  to  determine  these  properties  experimentally. 
Particle  shape  can  be  of  considerable  importance  in  some  cases,  as  in  the  comparison  of  water 
droplets  and  ice  crystals.  In  table  5  we  see  the  parameters  for  the  Research  Model  2 
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Fig.  10.  Description  of  trade-off  factors  in  the  modeling  of  atmospheric  obscurants 
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Table  4.  Assessment  of  Research  Model  1  Input  Parameters 
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Table  5.  Assessment  of  Research  Model  2  Input  Parameters 

Here  we  have  a  field  experiment  in  which  there  is  some  control  of  the  condition.  The  experimenter 
can  at  least  determine  the  time  of  day,  season,  and  location  for  the  experiment.  Also,  time  is  usually 
not  an  important  factor,  so  that  one  can  set  up  equipment  and,  if  necessary,  perform  the 
measurement  several  times.  Thus,  there  is  a  high  level  of  knowledge  associated  with  the  experimental 
design  of  the  input  parameters,  although  a  lesser  amount  with  the  actual  data  because  of  the  lack  of 
sufficient  knowledge  in  the  weather  parameters.  The  attenuation  coefficients  and  the  single¬ 
scattering  albedo  are  quite  important.  For  some  situations  it  is  not  of  critical  importance  to  know  the 
phase  function.  For  an  “benign”  or  passive  military  situation  the  parameters  of  importance  are 
indicated  in  Table  6.  Here  we  have  the  opposing  force  in  view  but  no  immediate 


(  m  OsMipMS 

[  TbfeBsnsittance 

Iliil  Medium .  ■ 

.  ..  .  Ujwtd  ixvedstim 

•;Oe6metiiy  i 

■Kna 

.  High 

Table  6.  Assessment  of  Operational  Model  1  Input  Parameters 
engagement  is  anticipated  so  there  is  no  time  constraint.  We  have  limited  knowledge  of  the 


background  but  we  can  obtain  sufficient  data  on  the  meteorological  conditions.  It  is  important  to 
have  information  on  the  LOS  transmittance  and  the  radiance  but  knowledge  of  such  information  may 
be  somewhat  limited  because  of  denied  access  to  the  entire  area.  The  output  parameters  that  are  of 
importance  are  the  contrast  and  signal-to-noise  ratio,  and  for  infrared  systems,  the  ranges  associated 
with  the  minimum  detectable  and  minimum  resolvable  temperatures.  Finally,  for  a  full  military 
engagement  the  conditions  are  indicated  in  Table  7.  Here,  almost  all  input  quantities  are  important 
but  knowledge  of  them  can  be  quite  limited.  Even  the  system-level  models  may  not  be  appropriate 
for 
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Table  7.  Assessment  of  Operational  Model  2  Input  Parameters 

the  situation.  The  third  column  indicates  that  knowledge  of  the  input  parameters  may  be  to  low  for  a 
successful  mission.  Factors  to  be  considered  in  the  Operational  Model  2  are  possibly  severe  time 
constraints  as  well  as  the  rapid  change  in  the  values  of  the  input  parameters  as  military  action  takes 
place. 

6.0  Problems  (Models  and  Data) 

6.1  Models 

The  basic  models  for  the  calculation  of  the  microphysical  data  for  the  obscurants  are  generally  quite 
good.  This  is  also  true  for  the  transmission  and  radiative-transfer  models  that  are  used  for  the 
calculation  of  the  radiance  through  a  medium.  What  is  lacking  at  the  next  higher  level  model  (in  a 
realistic  environment)  is  a  good  description  of  the  properties  of  the  medium  with  respect  to  time  and 
space  as  well  as  the  appropriate  mathematical  description  of  radiation  in  this  changing  environment. 
What  must  be  realized,  however,  is  that  even  if  a  sufficiently  advanced,  detailed,  deterministic, 
operational  model  were  to  be  developed,  the  results  would  not  be  exact  because  of  the  uncertainties 
inherent  in  the  limited  data  on  which  the  models  depend.  Thus,  it  might  be  more  reasonable  to 
develop  a  stochastic  model  that  predicts  probabilities  for  the  critical  quantities  in  the  operational 
mode  based  upon  the  partially  measured  probability  distribution  functions  that  characterize  the 
statistics  of  a  particular  quantity. 


6.2  Data 

A  fundamental  question  must  be  asked.  How  much  do  we  know  about  the  nature  of 
atmospheric  obscurants  for  any  region  of  the  globe  for  any  period  of  time?  Table  8  indicates  the 
obscurants  with  an  assessment  of  the  degree  of  uncertainty  in  the  critical  parameters  associated  with 
those  obscurants. 
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Table  8.  Assessment  of  the  status  of  operational  models  and  data  for  the  determination  of 

obscurant  properties  on  a  global  basis. 

In  almost  all  cases  the  basic  models  that  are  used  for  the  determination  of  the  microphysical 
quantities  and  the  transfer  of  radiation  either  can  be  developed  or  are  already  in  good  condition.  The 
major  problem  for  the  operational  models  lies  in  the  mathematical  description  of  the  spatial  and 
temporal  variability  of  the  concentration  of  the  obscurants.  There  is  an  inadequate  representation  of 
the  realistic  conditions  to  be  used  for  the  basic  models.  Usually,  the  situation  is  even  worse  for  the 
collection  of  data. 

This  is  always  limited,  of  course,  and  the  problem  then  becomes  one  of  careful  experimental 
design,  even  for  an  actual  military  engagement 


7.0  Improvements 


How  can  we  improve  the  operational  models?  There  are  two  aspects  to  the  problem.  First,  as 
indicated  in  Table  9,  one  can  develop  more  realistic  intermediate  models  that  take  into  account 
either  the  actual  spatial  and  temporal  variability  of  the  obscurants  or  their  probabilistic  nature  with 
the  use  of  stochastic  models.  Second,  one 
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Table  9.  Assessment  of  improvements  for  operational  models  and  data  for  the  determination  of 

obscurant  properties  on  a  global  basis. 


can  improve  on  the  data  collection  methods  that  are  used  to  provide  the  data  needed  as  input  to  the 
computational  models. 

8.0  Conclusions 

It  must  be  emphasized  that  in  almost  all  cases  for  obscurant  models  we  already  understand  the 
basic  physics  of  the  interaction  processes.  What  is  distinctly  lacking  is  a  clear  understanding  of  the 
variable  nature  of  these  obscurant  properties  and  how  to  relate  the  variable  properties  to  the 
necessarily  sparse  data  that  are  measured  as  input  to  the  models.  Therefore,  there  are  two  major  steps 
that  must  be  taken  to  improve  the  overall  fidelity  of  something  that  one  might  refer  to  as  the 
“complete”  operational  model. 

1.0  Most  of  the  current  obscurant  models  are  of  the  classic  “textbook”  type  in  that  they  use 
simple  representations  for  the  geometry  and  variability  of  the  obscurants.  Hence,  they  are  of  limited 
use  for  a  realistic  portrayal  of  the  modern  battlespace  environment.  This  situation  can  be  improved 
by  developing  more  realistic  geometries  for  the  expected  scenarios  and  better  algorithms  for  the 
connection  between  the  basic  obscurant  properties  and  the  standard  meteorological  data.  In  addition, 
one  should  develop  stochastic  models  at  least  for  the  purpose  of  examining  the  statistical  nature  of 
the  obscurants  and  to  provide  estimates  of  uncertainties  in  the  final  system-level  output  quantities 
needed  for  decision  making. 

2.0  There  definitely  needs  to  be  an  improvement  with  the  data  collection  process,  in  terms 
of  the  type  of  data,  the  amount,  frequency,  and  fidelity.  Fortunately,  much  of  this  work  can  be 
performed  now,  even  with  limited  data  sets.  Data  acquired  by  the  NASA,  NOAA,  and  DoD  satellites 
over  many  years  can  be  assembled  from  existing  catalogs.  Data  exist  on  soil  type  and  conditions  over 
extended  regions  of  the  globe,  which  will  provide  information  on  dust  generation.  Meteorological  and 
climatological  data  can  be  analyzed  with  regard  to  conditions  for  the  formation  of  haze,  fog,  and 
clouds  for  various  areas  of  interest.  With  respect  to  future  measurements,  NASA  has  the  Earth 
Observing  System  (BOS)  which  will  provide  useful  information  on  models  and  algorithms  for  the 
satellite  measurement  of  crucial  optical  properties  of  aerosols  and  hydrometeors.  More  work  is  being 
done  with  lidar  for  the  measurement  of  these  optical  quantities  and  RPV’s  can  certainly  be  used  for 
surveillance  situations. 

With  these  improvements  in  operational  models  and  data  collection  methods,  military 
commanders  of  the  future  should  have  more  reliable  and  realistic  techniques  for  the  analysis  of 
natural  and  anthropogenic  obscurants  in  the  modern  battlespace  arena. 
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ABSTRACT 

Modem  combat  vehicles  rely  upon  advanced  sensors,  such  as  Forward  Looking  Infrared 
(FLTR)  sensors,  image  intensifiers,  and  low4ight  television,  to  detect,  acquire,  and  defeat  threat 
vehicles.  These  sensors  increase  in  importance  under  degraded  visibility  conditions.  Factors  such  as 
detection  range;  time  required  to  detect;  and  probability  of  detection  are  crucial  in  determining  who 
fires  first  in  an  engagement.  The  first  shot  can  also  be  the  only  shot;  therefore,  firing  on  the  correct 
target  first  can  also  increase  vehicle  survivability.  This  paper  addresses  an  attempt  to  model  this 
comparison,  using  a  meeting  engagement  as  the  test  case.  On-board  obscurant  assets  were  the  only 
materials  played.  Vehicle  self-defense  obscurants  were  modeled  in  the  Combined  Obscuration  Model 
for  Battlefield-Induced  Contaminants  (COMBIC).  COMBIC  outputs  were  linked  to  input  files  for  the 
ACQUIRE  target  acquisition  model.  ACQUIRE  was  used  to  model  acquisition  probabilities;  time 
requirements;  and  range  of  acquisition  for  specified  vehicles,  using  a  range  of  several  possible 
sensors.  These  factors  were  compared,  for  hunter-target  pairs,  using  both  friendly  and  threat  vehicles 
as  the  hunter.  Results  and  insights  gained  were  summarized,  and  additional  applications  were 
described. 


1.  INTRODUCTION 

There  are  many  ways  to  model,  view,  or  simulate  obscurant  clouds.  There  are  also  several  ways  to 
simulate  vision  through  the  obscurant  cloud.  There  was  no  method  to  use  both  sets  of  information  to 
perform  one-on-one  or  one-on-many  analyses.  This  paper  was  written  to  demonstrate  the 
methodology  used  in  linking  obscurant  effects,  from  aerosol  models,  to  anticipated  results  from 
sensor  vision  models.  The  linkage  methodology  was  developed  by  the  U.S.  Army  Research 
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Laboratory  (ARE),  to  provide  a  standard  methodology  and  procedure  for  linking  obscurant  conditions 
to  the  effects  induced  on  the  sensors.  The  methodology  and  results  described  below  were  used  for 
several  ground  and  munition  system  programs  analyzed  by  personnel  at  the  Survivability/Lethality 
Analysis  Directorate  (SLAD) . 


2.  BACKGROUND 

Several  ground  system  programs  have  needs  for  preliminary  system  analyses  by  SLAD.  The 
analyses  are  needed  to  measure  either  obscurant  effects  on  their  sensor  package,  or  survivability 
enhancements  from  using  proactive  or  reactive  obscurants.  Other  ground  systems  or  munitions  require 
analysis  of  system  effects  under  experimental  conditions,  and  extensions  of  this  analysis  into  other 
climatic  or  weather  regions.  Experiments  were  limited  by  the  project  flinds,  available  to  either  SLAD 
or  the  customer,  because  field  experiments  are  vey  expensive.  Threat-based  effects,  or  effects  under 
different  climates  and  theaters,  were  not  addressed  well  in  some  analysis  efforts  because  there  was  no 
common  method  or  procedure  to  use  in  an  analysis.  There  was  no  apparent  system  to  link  information 
from  atmospheric  or  aerosol  models  to  sensor  or  vision  models.  The  models  might  also  omit  or 
understate  aerosol  effects,  such  as  scatter  or  radiance,  because  their  focus  appears  to  be  transmission 
effects. 


SLAD  uses  a  standard  taxonomy  structure  to  address  survivability  and  lethality  issues  (Figure 
1).  The  taxonomy  is  a  useful  tool,  but  requires  some  care  in  use  for  analyzing  sensor  effects.  The 
methodology  described  below  is  a  way  to  implement  the  taxonomy,  with  respect  to  obscurant  and 
aerosol  effects.  This  analysis  methodology  was  built  to  account  for  modeled  weather  and  aerosol 


Figure  1.  Overview  of  SLAD  Taxonomy  (Obscurants  Emphasis) 


effects  in  different  climates;  use  aerosol  model  results  as  inputs  for  the  vision  models;  and  analyze  the 
results  in  terms  of  battlefield  capabilities. 


3.  CONSTRAINTS  ON  ANALYSIS  AND  MODELING 


The  sensor  and  model  analyses  were  restricted  to  relatively  small  spaces,  to  reduce  analysis 
time  and  to  focus  on  areas  of  most  interest  first.  Some  of  the  treatments  for  atmospheric  conditions 
and  energy  interaction  have  limits  on  the  approximations  used.  The  models  all  have  boundary 
conditions,  and  rely  upon  certain  assumptions.  It's  possible  to  overstep  these  boundaries  and 
assumptions  if  the  models  are  not  linked  properly.  These  constraints  are  described  in  succeeeding 
paragraphs. 

3.1  SENSORS 

Direct-fire  acquisition  systems  (ground  to  ground  or  air  to  ground)  were  used  for  the  model 
process.  The  sensors  used  in  this  study  were  first  and  second  generation  forward  looking  infrared 
(FLIRs),  for  direct  fire  applications  (cannon,  missile).  Generic  sensor  descriptions  were  modeled  from 
ACQUIRE'  standard  inputs.  Sensor  analysis  required  the  operator  of  a  hunter  vehicle  to  be  able  to 
detect,  identify,  and  then  engage  a  possible  target.  The  sensors  used  were  based  on  open  literature 
citations  for  NATO  and  former  Soviet  Union  AFVs.  Given  the  state  of  flux  in  some  regions  of  the 
world,  there  may  be  potential  for  sensor  upgrades  as  part  of  "third  party"  or  customized  platform 
improvements. 

The  sensor  analysis  used  limits  on  search  time  in  the  field  of  regard  and  on  search  time  within 
a  given  field  of  view.  These  times  were  kept  short,  to  represent  the  times  that  could  occur  in  a  meeting 
engagement  between  two  (small)  forces.  The  analysis  focused  on  the  search  and  acquisition  situations 
likely  to  occur  either  early  in,  or  at  the  end  of,  a  meeting  engagement.  The  vehicles  here  were 
constrained  to  find  opposing  targets  in  the  early  stages  of  engagement,  for  direct  fire  combat.  Similar 
constraints  also  apply  for  forces  disengaging  from  combat  for  repair  or  resupply 

3.2  CLIMATES  AND  THEATERS 

Climate  conditions  possible  in  southwest  Asia,  northeast  Asia,  and  central  Europe  were 
modeled,  to  provide  finite  boundaries  on  the  problem  space.  The  climate  areas  were  selected  because 
they  represent  high  visibility  areas,  commonly  seen  on  broadcast  and  cable  news.  These  areas  show 
apparent  high  levels  of  ethnic  or  international  tension,  exacerbated  by  resource  shortages  or  inefficient 
economies.  They  also  represent  a  reasonable  cross-sections  of  arms  sales  for  NATO  and  former 
Soviet  systems.  Daytime  climate  conditions  are  described  in  Table  1  for  Middle  East  desert  conditions, 
obtained  from  CLIMAT  (three  most  likely  conditions).  The  values  are  representative  of  possible 
weather  conditions,  natural  aerosols,  and  wind/stability  combinations.  The  climate  conditions  are 
further  bounded  by  limiting  the  ground  range  of  interest  to  10km,  and  air  altitudes  to  about  1km.  This 
simplified  the  atmospheric  modeling,  while  avoiding  any  overemphasis  on  certain  extinction  effects. 
This  bounds  the  line  of  sight  value  for  open,  gently  rolling  terrain. 
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TABLE  1.  DAY  CONDITIONS,  MIDDLE  EAST  DESERT  (SPRING) _ 

Type  Description  Temp,  RH,  Visibility,  Windspeed,  Pasquill 


deg  C  %  km  m/s  Category  6 

Dust  with  visibility>  3  km  28.2  25.9  8.5  6.7  D/C 


15 

Noweatherandabsolute 
humidity  <10  gm/m3 

21.1 

34.6 

17.7 

3.8 

BID 

16 

No  weather  and  absolute 
humidity>  10  gm/rn3 

25.0 

54.0 

15.2 

3.8 

CID 

Conditions  15  and  16  represent  the  majority  of  conditions  to  be  expected  during  daylight  hours  (1000 
-  1400).  This  includes  warm  temperatures,  moderate  winds,  and  a  neutral  to  slightly  unstable  air 
condition.  Obscurants  used  under  these  conditions  will  have  moderate  duration. 


3.3  OBSCURANTS 

The  obscurants  used  in  this  study  were  taken  from  unclassified  sources  and  from  unclassified 
NATO  documentation/descriptions.  The  phosphorous  and  bispectral  grenades  studied  were  L8A3  and 
M76  screening  grenades,  used  in  conjunction  with  M239  or  M243  series  smoke  grenade  launchers. 
The  UK  L8A3  was  adopted  (with  its  launchers)  by  the  U.S.  Army  in  1976.  The  M76  IR  screening 
grenade,  which  is  used  with  the  same  launchers,  was  type  classified  in  1986.  Both  grenades  have  been 
used  in  field  experiments  and  have  been  used  in  NATO  exercises  and  tests.  The  L8A3  smoke  grenade 
produced  scatter  and  attenuation  in  the  visible  and  near  IR  bands;  some  far  IR  attenuation  occurred,  in 
combination  with  increased  clutter.  The  M76  produced  attenuation  in  all  bands  from  visual  through 
far  IR. 


Three  mechanisms  are  postulated  for  obscurant  effects:  absorption,  scatter,  and  radiance 
(emission).  Attenuation  is  a  combination  of  absorption  and  scattering;  this  is  commonly  considered 
the  principal  effect  of  obscurants.  Absorption  decreases  radiation  propagation,  in  a  given  band, 
through  the  material.  The  energy  absorbed  can  be  re-radiated  at  different  frequencies,  or  can  be  re¬ 
radiated  out  of  the  path  to  the  receiver,  resulting  on  signal  loss.  Scatter  can  reflect  laser  or  radio 
frequency  (RE)  energy,  depending  on  the  obscurant,  creating  false  signals  or  cluttered  returns. 
Radiation  can  be  scattered  into  or  out  of  the  signal  path.  Radiance  involves  the  release  of  large 
amounts  of  energy  from  pyrophoric  materials  or  from  warm  obscurant  clouds.  This  produces 
additional  hot  spots  or  warm  areas  in  a  scene,  changing  the  background  distribution  and  altering  the 
signal  to  noise  ratio.  The  effect  is  most  pronounced  in  the  mid  and  far  IR. 

The  taxonomy  describes  a  strategy  for  analyzing  effects,  from  initial  conditions  present 
through  the  degraded  capabilities  for  the  system.  Obscurant  conditions  can  include  reduced 
transmission,  radiation  scatter,  and  emission  (radiance).  The  resulting  degraded  conditions  are: 


a.  Contrast  reduction.  Attenuation,  which  is  a  combination  of  absorption  and  scatter,  can  alter  a  target's 
apparent  contrast  with  the  background.  This  can  make  it  harder  to  distinguish  a  target  from  its 
background. 

b.  Signal  reduction.  Radiation  scatter  through  an  obscurant,  or  through  a  hazy  atmosphere  ("clear  air"), 
can  alter  the  apparent  structure  information  for  the  target.  Out-of-path  scatter  can  blur  edges  or  feature, 
which  makes  it  harder  to  detect  or  classify  a  target. 

c.  Clutter.  Emissive  materials  can  create  relatively  warm  obscurant  clouds  or  hot  elements  in  a  scene. 
This  additional  clutter  can  alter  a  scene's  structure,  and  can  hide  or  alter  target  structure.  They  can  also 
introduce  false  targets  or  false  features  into  the  scene. 

Obscurants  were  placed  with  a  tail  wind,  to  move  the  obscurant  from  the  target  vehicle  toward  the 
observer  (hunter)  (Figure  2).  This  also  can  be  modeled  for  head,  cross,  or  quartering  winds.  The  range 
description  also  shows  relative  range  scale,  and  the  size  of  range  cells  used  for  estimating  obscurant 
concentrations  and  transmission. 


Figure  2.  Target  Space  Description  for  Analysis 


4.  METHODOLOGY 


The  methods  used  below  were  intended  to  describe  target  acquisition  parameters,  given  known  or 
modeled  inputs  on  the  sensor  type,  atmosphere,  and  other  conditions.  This  methodology  also  looked  for 
areas  where  the  models  did  not  interact  well,  or  where  the  input  information  could  not  be  easily  translated 
between  models. 

4.1  ATMOSPHERIC  AND  AEROSOL  CONDITIONS 

The  study  methodology  was  based  on  the  need  to  estimate  transmission  through  range  cells  along 
a  path  from  the  target  to  the  receiver.  Basic  atmospheric  transmission  was  modeled  in  XSCALE2,  using 
climatic  conditions  (2-3  most  common  cases)  from  CLIMA~f.  COMBI-  was  used  to  model  obscurant 
transmission  within  the  area  of  interest,  in  the  small  range  cells.  The  composite  relation  of  range  and 
transmission  was  used  as  an  atmospheric  input  to  ACQUIRE. 

4.2  ACQUISITION  MODELING 

ACQUIRE  was  used  to  model  target  acquisition  by  IR  imagers  (first  or  second  generation  FLIR). 
Unclassified  target  and  sensor  descriptions  were  used  for  this  analysis.  ACQUIRE  outputs  were  used  to 
get  estimates  for  probability  of  detection  at  different  ranges,  and  also  to  obtain  estimates  for  time  required 
to  find  a  target  at  range.  The  target  was  an  Mi-sized  target,  with  a  given  temperature  of  2  degrees  C  above 
background.  Low  and  moderate  clutter  conditions  were  used.  Target  range  was  fixed  at  2km  for  the  trial 
cases  presented  here,  to  bound  the  problem  space. 


4.3  MODEL  LINKAGE 

COMBIC  and  ACQUIRE  were  linked  by  means  of  an  Excel (TM) 5  spreadsheet.  COMB  IC  was 
used  to  develop  range  cell  profiles  of  transmission  in  an  obscurant  cloud,  and  also  to  develop  cross-axis 
profiles  of  the  cloud  width.  The  along-axis  profiles  were  combined,  in  the  spreadsheet,  with  atmospheric 
extinction  determined  from  CLIMAT  and  XSCALE.  This  provided  the  range  -transmission  pairs  needed 
to  explicitly  define  an  atmosphere  condition  for  ACQUIRE.  Clutter  could  be  simulated  only  by  altering 
the  number  of  cycles  needed  for  response  (n50  for  detection,  recognition,  etc.)  under  the  Johnson  criteria. 
Target  contrast  changes  were  not  easy  to  describe  for  ACQUIRE.  The  ACQUIRE  outputs  for  these 
conditions  were  then  imported  back  into  the  spreadsheet.  The  data  were  parsed  and  plotted  to  provide 
graphic  representations  of  probability  of  detection  (Pd)  and  range;  Pd  and  time,  and  range  and  time  for  a 
given  Pd  condition.  The  spreadsheet  related  two  different  input-output  requirements  without  needing  an 
elaborate  interface  or  re-coding  effort.  The  spreadsheet  also  made  it  possible  to  change  assumptions  or 
graphical  techniques  rapidly.  The  graphical  products  could  also  be  copied  or  linked  easily  to  other 
applications,  such  as  presentation  or  word  processing  packages,  for  easier  communication  of  results. 


5.  RESULTS 


5.1  AEROSOL  AND  ATMOSPHERIC  EFFECTS 

CLIMAT  was  run  first,  to  get  predictions  for  climatic  types  possible  in  the  areas  of 
interest.  The  three  highest  probability  conditions  noted  in  CLIMAT  were  used  in  COMBIC,  to 
model  effects  from  natural  aerosols  in  combination  with  the  man-made  obscurants.  One  set  of 
southwest  Asia  (SWA)  conditions  is  presented  as  an  example  case.  COMBIC  was  used  to  model 
spring  day  conditions  for  climate  condition  16  (wind  8.5  kts  (3.8  mis),  Pasquill  category  C,  day, 
temp  25  deg  C,  RH  54%).  Attenuation  profiles  are  shown  below  for  6  M76  grenades;  mix  of 
M76  and  L8A3  grenades;  and  L8A3  smoke  grenades  (6)  with  vehicular  dust  effects.  The  wind 
direction  was  a  tail  wind  behind  the  target  vehicle,  blowing  toward  the  observing  vehicle. 
Figures  3-5  shows  the  transmission  time  history  along  the  center  axis  of  the  modeled  line  of 
sight.  Figure  6  describes  the  approximate  cloud  effect  across  the  wind  axis. 


Figure  3.  Transmission  along  LOS  for  mixed  salvo  of  six  grenades 
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Figure  6.  Cross-win  axis  profile,  Salvo  of  6  M76  grenades  (5  meter  cells) 


The  optical  density  of  the  cloud  changes  with  time  after  dissemination,  wind  speed,  atmospheric  stability, 
and  other  factors.  Optical  densities  (OD)  of  1  or  2  (37%  or  16%  transmission)  can  occur  relatively  fast, 
and  can  remain  on  the  line  of  sight  for  periods  of  time.  Many  advanced  sensors  have  performance 
requirements  for  obscurants  expressed  in  terms  of  OD  or  transmission. 


5.2  ACQUISITION  EFFECTS  FROM  OBSCURANTS 


Obscurant  profiles  were  shown  in  Figures  1-3,  with  early  cloud  development  described.  These  clouds 
continued  to  develop  for  about  30s,  then  began  to  disperse.  Direct  fire  weapon  effects  involve  obscurant 
effects  on  FLIRs  or  other  sensors.  Nominal  missile  or  projectile  flight  times  are  shown  in  Table  2). 


TABLE  2.  ESTIMATED  TIME  OF  FLIGHT  FOR  DIRECT  FIRE  ENGAGEMENTS 


Munition  Class  Nominal  Velocity,  mis  Nominal  Time  of  Flight  to  Target  at  Range,  5 

lkm  2km  3km  4km 


ATGM 

200 

5 

12 

25 

30 

Cannon  (KB  or  CE) 

2000 

0.5 

1 

2 

3 

Table  2  shows  that  unguided  attacks  (cannon  fire)  arrive  very  quickly  after  engagement  and 
firing;  obscurants  may  not  have  much  effect  afier  engagement  begins,  at  short  range.  However,  the  guided 
munitions  (ATGM)  can  require  sufficient  time  of  flight  to  encounter  a  cloud  of  OD  1  to  2  (transmission 
below  40%)  for  an  area  20-40m  across.  In-flight  and  terminal  guidance  can  be  affected  by  interfering  with 
the  operator's  scene  picture  (obtained  from  optics  or  FLIR)  or  by  disrupting  data  links.  The  operator  can 
lose  lock  on  the  target.  The  degradation  mechanisms  are  contrast  reduction  and  reduced  signal  strength. 
U.S.  doctrine  is  to  use  the  prevailing  winds,  and  cloud  movement,  to  hide  a  vehicle  behind  the  self- 
defense  obscurant6.  The  vehicle  can  then  enter  defilade  behind  terrain  features  while  either  evading  attack 
or  returning  fire. 

The  cases  above  show  obscurant  effects  for  targets  acquired  by  advanced  sensors.  This  begs  the 
question  that  detection  has  already  occurred.  Detection  effect  from  obscurants  were  modeled  with 
ACQUIRE,  and  are  described  below  (Figures  7-8).  The  cases  shown  were  the  M76  6  grenade  salvo,  and  a 
salvo  of6  L8A3  grenades  with  vehicular  dust.  The  mixed  salvo  (L8A3  and  M76)  and  L8A3  salvo  with 
dust  were  modeled  with  an  increased  clutter  level,  due  to  small  fires  and  radiance  from  the  RP  pellets.  An 
Ml  size  target,  with  a  background  temperature  difference  of2  degrees  C,  was  used  for  a  target  vehicle.  The 
acquisition  sensor  was  an  "average"  first  generation  FLIR. 


f 


Figure  8.  IbcbuKJiiy  of  detection  K7&  pSS>:y^ 


6. ANALYSIS  OF  ACQUISITION  EFFECTS 


Target  acquisition  was  analyzed.  This  meant  examining  acquisition  probabilities  at  given  ranges,  as  well 
as  times  required  to  detect  and  acquire  targets. 

6.1  TARGET  DETECTION 

The  probability  functions  (Figures  7-8)  show  the  probability  of  detection  (wide  or  narrow  field  of  view 
(FOV)),  for  times  tending  to  infinity  (ideal  case).  A  system  attempting  to  acquire  the  target  must  first 
detect  it.  Detection  may  probably  be  in  the  wide  FOV,  but  may  be  in  the  narrow  FOV  if  the  observe  had 
time  to  scan  the  operating  area  first.  The  target  would  be  hard  to  find  if  a  6  grenade  M76  salvo  is  used  (Pd 
about  70%  at  2  km,  in  2  5,  Pd  about  45%  at  8s).  The  L8A3  grenade  salvo,  with  vehicular  dust  accounted 
for,  becomes  veiy  hard  to  detect  at  2km  (Pd  (wide)  about  15%,  Pd  (narrow)  about  80%)  for  a  first 
generation  system;  more  important  is  the  effect  of  the  combined  dust  plume  and  phosphorous  cloud.  The 
target  becomes  very  difficult  to  detect  at  ranges  beyond  2  km,  due  to  the  dense  cloud  produced.  The  target 
would  be  able  to  hide  or  maneuver  behind  this  veiy  dense  cloud.  This  cloud  produces  even  stronger 
effects  at  times  of  4s  and  later. 

6.2  TIME  REQUIREMENTS 

Time  required  to  detect  a  target  also  becomes  important.  The  probabilities  in  Figures  were 
developed  using  a  30s  search  time  over  a  60  degree  field  of  regard.  The  time  requirements  for  a  high 
probability  of  detection,  for  the  above  grenade  uses,  is  shown  in  Figure  9  below.  These  times  were 
developed  at  2s  after  grenade  detonation.  Probability  of  detection  was  chosen  as  70%  to  give  the  hunter  a 
better  than  even  guess  at  the  target,  while  keeping  the  time  required  to  detect  below  the  infinite  amount 
needed  for  a  perfect  detection.  Its  target  can  be  detected,  but  it  can  take  80  seconds  to  achieve  a  good 
detection  in  the  presence  of  obscurants  (M76).  The  target  may  not  be  detectable  at  the  studied  range  when 
a  mixed  salvo,  or  an  L8A3  salvo  with  dust  is  considered.  The  contrast  level  is  reduced  and  background 
clutter  is  increased. 


6.3  OBSCURANT  IMPACTS 


The  ACQUIRE  detection  time,  for  clear  air  conditions  (before  obscurant  use),  show 
approximately  33  seconds  for  detection  by  either  hunter  or  target  at  2  km  range.  If  the  target  vehicle  is 
found  first,  then  obscurant  effects  are  as  described  above  (limited  reaction  time).  If  the  observe  (hunter) 
vehicle  is  found  first,  the  target  can  employ  obscurants,  make  evasive  maneuvers,  and  attempt  to  fire  or 
disengage.  If  the  target  vehicle  can  survive  for  about  6-8  seconds,  the  probability  of  detection  drops 
significantly  and  the  required  search  time  grows  large.  This  is  a  combined  effect  of  increased  range  and 
obscurant  cloud  growth.  The  probability  of  engagement  drops  because  the  target  is  much  harder  to  find. 

The  observer  vehicle  must  then  decide  whether  to  attempt  reacquisition  or  disengage  and  find  a  less  waiy 
target. 

The  depictions  for  phosphorous  grenades  are  of  interest,  for  the  possible  clutter  impacts.  The 
changes  in  discrimination  values  (n50)  are  based  on  changes  in  the  scene  clutter  and  on  some  possible 
false  targets  introduced  into  the  scene,  when  viewing  the  area  from  a  2km  distance.  The  changes  have 
moderate  duration  (30-60s),  depending  on  local  climate  and  meteorology  conditions.  This  can  be 
sufficient  time  to  alter  the  search  and  acquisition  characteristics.  Other  radiant  materials,  such  as  grenades 
from  other  nations  or  artilleiy/mortar  fire  with  WP  ammunition,  can  have  similar  effects.  Figures  10  and 
1 1  show  two  time  histories  of  an  RP  grenade  image.  The  burning  RP  pellets 


are  distributed  across  a  1  Om  diameter  area,  based  on  the  distance  and  resolution  of  the  Agema  imager. 
These  hot  spots  and  warm  cloud  elements,  when  viewed  from  a  distance,  cold  add  clutter  to  the  scene. 
They  may  also  be  misinterpreted  as  having  target-like  features,  especially  if  viewed  with  a  low-resolution 
sensor.  Images  and  data  like  those  below  were  used  to  justify  the  increased  clutter  level  for  the 
phosphorous  grenade  modeling 


6.4  FEASIBILITY  OF  MODEL  LINKAGE 


COMBIC  produced  large  amounts  of  data  for  the  obscurant  cloud  transport  and  fate.  The  output 
file  could  be  imported  into  Excel(TM)  with  little  trouble,  as  a  delimited  file.  This  file  needed  to  have 
header  information  pruned,  and  the  output  data  sorted,  to  be  of  further  use.  Atmospheric  transmission 
coefficients  could  be  extracted  from  XSCALE  and  CLIMAT  with  little  difficulty,  and  used  as  "constants" 
for  a  given  environmental  run.  It  was  possible  to  take  time-based  slices  of  the  cloud,  determine  where  the 
cloud  boundaries  appeared,  and  build  a  small  table  for  range  and  transmission.  These  columns  were 
exported  as  delimited  data  to  become  part  of  the  ACQUIRE  inputs.  Multiple  ACQUIRE  runs  were 
conducted  using  these  exported  files,  with  the  correct  run  separators  supplied.  This  reduced  the 
ACQUIRE  run  time  by  doing  batch  operations.  The  data  slices  were  cut  off  at  about  3  Os  after  detonation 
of  grenades,  as  the  clouds  would  begin  to  disperse  then.  The  operations  could  be  conducted  with 
relatively  simple  spreadsheet  macros,  after  initial  manual  efforts  to  determine  that  the  correct  data  were 
used  and  processed. 

ACQUIRE  run  analysis  was  simpler,  as  this  required  parsing  of  portions  of  the  ACQUIRE  output 
files.  This  could  be  accomplished  by  the  appropriate  macros,  to  speed  up  processing.  The  most  time- 
consuming  portion  of  the  ACQUIRE  analysis  was  determining  what  variables  to  graph,  and  to  show  what 
information  as  being  most  interesting. 

The  n50  vaues  used  in  this  analysis  were  based  on  analysis  by  other  agencies  (AMSAA,  CECOM 
Night  Vision  Directorate)  for  similar  sensors.  The  analysis  was  done  for  benign  conditions,  principally, 
because  few  obscurant  data  points  were  available  for  the  ranges  and  scene  conditions.  The  n50  value 
appears  related  to  the  false  target  density  and  to  an  estimate  for  scene  clutter  levels  (low  through  high) . 
Attenuating  obscurants  can  reduce  clutter  in  the  local  area  by  suppressing  clutter  elements  in  the 
background,  so  the  n50  values  were  not  raised  much.  Emissive  materials,  such  as  phosphorous,  can 
introduce  more  clutter  and  possible  false  targets.  The  n50  values  were  raised  moderately,  to  account  for 
these  combined  effects.  Additional  obscurant  data,  for  the  backgrounds  and  clutter  levels  studied,  would 
allow  for  developing  a  non-benign  set  of  n50  relations;  this  would  ease  the  task  of  linking  model  results 
and  obtaining  relevant  predictions. 


7.  CONCLUSIONS 

7.1  Fielded  or  type  classified  obscurants  can  affect  advanced  sensors  used  to  detect  and  acquire  targets. 
This  can  have  impact  on  system  performance  modeling.  Obscurant  effects  can  be  modeled  in  COMBIC 
and  linked  with  programs  such  as  ACQUIRE.  Follow-on  modeling,  with  other  obscurants,  can  be 
conducted  to  estimate  effects  for  other  common  materials. 

7.2  ACQUIRE  can  handle  obscurants  as  an  explicit  Beer's  Law  entry,  or  as  an  implicit  portion  of  an 
atmosphere  profile.  This  accounts  for  direct  transmission  reduction,  but  does  not  necessarily  account  for 
energy  scatter  and  transfer  from  the  surroundings.  The  additional  energy  from  out-ofpath  scatter,  sky  and 
ground  sources  can  induce  contrast  changes  and  can  affect  how  a  human  detects  a  target.  The  ACQUIRE 
modeling  team  should  discuss  the  implications  of  scene  models,  such  as  PILOT8  1,  with  SLAD  to 
examine  these  additional  effects. 


7.3  Models  such  as  COMBIC  and  ACQUIRE  can  be  linked  by  intermediaries  such  as  spreadsheet 
programs.  The  spreadsheets  were  very  useful  in  visualizing  the  obscurant  clouds  and  the  related  effects  on 
target  acquisition.  SLAD  should  continue  the  efforts  to  automate  the  data  extraction  and  transformation, 
and  make  this  linkage  process  more  efficient. 

7.4  Clutter  and  false  alarm  density  must  be  modeled  (indirectly)  as  changes  to  the  nSO  characteristic 
values  in  the  model.  These  effects  are  not  played  directly  in  the  model.  SLAD  analysts  are  working  on 
several  approaches  to  portraying  combined  effects  from  obscurants,  other  aerosols,  and  false  targets  or 
induced  clutter.  This  can  provide  better  inputs  for  the  target  acquisition  models. 
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EW  TESTING  LESSONS  LEARNED 


Paul  H.  Berkowitz,  Executive  Vice  President  Track:  SOS/DST  Tuesday  6/16/98 

Electro-Radiation  Inc. 

ABSTRACT 

Electronic  Warfare  (EW)  testing  is  one  of  the  more  challenging  undertakings  in  the 
Avionics  community.  EW  tests  are  typically  fraught  with  a  myriad  of  problems  due  to  the 
inherent  complexity  of  tests  involving  multiple  vehicles,  radars,  data  collection,  and  data 
processing,  as  well  as  the  complex  nature  of  Electronic  Warfare  itself.  Electro-Radiation  Inc. 
(ERI)  has  been  at  the  forefront  of  EW  testing  for  many  years,  from  B-52  to  B-2  and  from  F- 101 
to  F-22.  While  it  is  impossible  to  prevent  all  problems,  it  is  possible  to  prevent  the  same 
problems  from  repeating.  This  paper  applies  many  of  the  lessons  ERI  learned  from  its  extensive 
EW  testing  experience,  and  offers  recommendations  of  how  to  avoid  repeating  them. 

1.0  INTRODUCTION 

Electro-Radiation  Inc.  (ERI)  has  been  a  leader  in  the  field  of  Electronic  Warfare  (EW) 
testing  for  many  years.  During  this  time,  it  has  been  seen  that  the  complexities  of  EW  testing 
create  an  enormously  challenging  environment.  A  typical  EW  flight  test  involves  multiple 
aircraft,  both  jammers  and  victims;  ground  test  radars;  ground  reference  radars;  airborne  reference 
radars;  a  central  facility  for  real  time  flight  and  test  control;  telemetry  and  displays  for  real  time 
observation;  data  collection;  post  data  processing  to  generate  error  information;  a  laboratory  to 
test  and  program  the  EW  system,  with  associated  signal  sources,  meters,  scopes,  monitors,  test 
boxes,  reprogramming  tools,  and  spares  for  emergency  repair/rework;  and  a  classified  work  area 
with  data  storage  for  manuals  and  test  data. 

For  any  single  day’s  test,  as  many  as  50  people  from  several  Government  agencies  and 
contractors  can  be  involved.  In  the  center  of  this  is  the  EW  tester,  who  has  responsibility  for 
about  100  variables  and  control  of  perhaps  3.  Given  this  complex  scenario,  it  is  not  surprising 
that  many  problems  arise.  It  is  virtually  impossible  to  run  such  an  enterprise  without  problems. 
However,  there  are  several  problems  that  tend  to  occur  quite  often.  It  is  these  “repeat  offenders” 
that  can  be  eliminated  fairly  simply,  with  some  careful  foresight  and  planning.  This  paper 
presents  several  of  these  problems,  and  recommendations  of  how  to  eliminate  them  in  the  future, 
with  the  benefit  of  ERI’s  years  of  EW  test  experience  hindsight. 

There  are  several  areas  where  issues  arise  in  EW  testing.  These  include: 

AIRCRAFT 

RANGE 

TEST 

DATA 
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2.0  AIRCRAFT  ISSUES 

When  a  new  piece  of  equipment  is  installed  in  an  aircraft,  it  must  be  integrated  both 
physically  and  functionally.  Most  aircraft  issues  are  related  to  the  physical  equipment 
installation.  Functional  integration  usually  proceeds  fairly  smoothly,  since  it  is  possible  to  test 
most  interfaces  with  the  actual  equipment  or  a  software  simulation  of  that  equipment.  Most 
problems  arise  when  the  physical  interface  is  different  on  the  aircraft  than  in  the  lab,  such  as 
cable  sizes  and  lengths;  or  when  spatial  functions,  such  as  Direction  Finding  (DF)  and  sector 
crossover,  are  being  tested  for  the  first  time. 

2.1  Cabling 

When  Line  Replaceable  Units  (LRUs)  or  “black  boxes”  are  tested  in  the  laboratory,  they 
are  usually  placed  side-by-side  on  a  bench  or  fixture,  with  relatively  short  interconnecting  cables. 
When  those  same  LRUs  are  installed  in  the  aircraft,  they  may  be  separated  by  tens  of  feet. 
Additionally,  the  actual  cable  runs  may  be  much  longer  than  that,  due  to  connectors,  bulkhead 
feedthroughs,  etc.  Figure  1  illustrates  these  potential  differences.  A  system  that  works 
perfectly  on  the  lab  bench,  may  encounter  problems  when  installed  in  the  aircraft  due  to  the 
different  cabling.  Cable  lengths  can  affect  signal  characteristics,  such  as  timing,  rise  and  fall  times, 
driver  loading,  and  voltage  drops. 


Timing  can  create  insidious  problems,  such  as  when  blanking  just  fails  to  cover  a  potential 
interferer,  and  a  sliver  of  undesired  signal  corrupts  system  performance.  ERI  experienced  this 
during  a  B-52  EW  flight  test.  A  processor  Line  Replaceable  Unit  (LRU),  or  “black  box”  was 
installed  near  the  crew  station,  and  a  direction  finding  (DF)  receiver  was  under  the  nose  radome. 
Because  of  the  size  of  the  B-52,  the  cable  run  was  tens  of  feet  long.  The  blanking  signal  to  the 
DF  receiver  to  protect  it  from  seeing  the  EW  system  transmission  was  arriving  just  late  enough  to 
intermittently  allow  the  interference.  When  the  problem  was  finally  diagnosed,  it  was  easily 
fixed  by  adjusting  the  blanking  signal  timing. 

Unexpected  voltage  drops  can  also  create  intermittent  anomalies  which  can  be  extremely 
difficult  to  diagnose  and  correct.  These  problems  are  not  limited  to  large  aircraft  like  B-52s.  A 
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recent  ERI  Global  Positioning  System  (GPS)  Interference  Suppression  Unit  (ISU)  test  on  a 
Falcon-20  business  aircraft  flights  were  lost  due  to  an  unexpected  voltage  drop  in  a  DC  power 
line.  The  line  losses  were  enough  to  drop  the  +5  volts  at  the  power  supply  down  to  +4  volts  at 
the  ERI  LRU.  To  further  complicate  the  issue,  the  voltage  was  high  enough  to  enable  ERI’s 
system  to  turn  on,  but  not  high  enough  for  the  circuitry  to  function  properly.  Two  flights  were 
lost  due  to  this  problem. 

The  best  solution  to  avoiding  installed  cabling  problems  is  to  use  the  same  cables  in  the 
laboratory  as  in  the  aircraft.  The  simplest  approach  is  to  have  two  cable  sets  built  for  the 
aircraft,  and  use  one  in  the  lab.  Then  if  any  timing,  loading,  or  loss  problems  arise,  they  can  be 
solved  in  the  lab.  If  schedule  or  cost  considerations  prevent  using  this  approach,  the  next  best 
option  is  to  obtain  the  aircraft  installation  drawings  and  estimate  the  installed  cable  lengths  and 
connections.  Then  a  lab  cable  set  can  be  built  to  the  same  design.  Both  of  the  examples  cited 
could  have  been  avoided  had  this  approach  been  adopted. 

2.2  DF  and  Sector  Crossover 

Direction  Finding  (DF)  and  sector  crossover  problems  are  very  common  in  EW  flight 
tests.  Often,  this  is  the  first  opportunity  to  actually  radiate  to  and  from  the  system,  which  is 
required  to  stimulate  the  DF  and  sector  crossover  functions.  Additionally,  this  is  almost  always 
the  first  time  these  functions  operate  under  dynamic  conditions.  To  complicate  the  issue,  there  is 
limited  control  of  the  environment  during  flight  test,  making  analyses,  diagnoses,  and  correction 
difficult.  Finally,  aircraft  installation  can  also  affect  performance,  due  to  alignments,  blockages, 
reflections,  etc.  These  problems  are  very  difficult  to  troubleshoot  in  flight.  The  true  data 
reference  requires  accurate  position,  heading,  and  attitude  data  for  the  aircraft.  Correlating  the  on¬ 
board  (DF)  data  with  the  off-board  (true)  data  is  a  data  processing  challenge.  Additionally,  there 
is  very  limited,  or  no,  real  time  observation  of  the  EW  system  possible  during  operation. 

There  are  three  parts  to  the  answer  for  DF  and  sector  crossover  issues.  Each  solution  has 
merit  on  its  own,  and  applying  all  three  is  ideal.  The  first  solution  is  to  place  the  system  in  an 
anechoic  chamber  in  the  laboratory.  The  chamber  does  not  have  to  be  huge,  or  super  “quiet”.  It 
need  only  fit  the  relevant  Black  Box  with  its  antennas  and  radomes,  and  be  large  enough  so  that 
both  the  system  antennas  and  test  antennas  are  operating  in  the  far  field.  The  isolation  must  be 
enough  to  ensure  personnel  safety,  and  prevent  interference  with  other  lab  activities.  This  will 
enable  radiating  tests  with  controlled  conditions.  Real  time  observation  of  all  parts  of  the  EW 
system  is  feasible,  and  correlation  between  measured  DF  and  true  data  is  simplified. 
Additionally,  a  full  set  of  laboratory  diagnostic  equipment  should  be  available  with  the  design 
experts  on  call.  The  DF  and  sector  system  performance  can  be  isolated  from  aircraft  installation 
effects,  resulting  in  a  well  defined  performance  baseline  prior  to  flight  test.  Dynamic  testing  is 
somewhat  limited,  but  even  that  can  be  simulated  to  some  degree  by  programming  a  threat 
generator  to  “fly”  through  a  defined  scenario. 

The  second  solution  is  to  test  the  system  installed  in  the  aircraft  in  the  Benefield 
Anechoic  Facility  (BAF)  at  Edwards  Air  Force  Base.  The  BAF  houses  the  largest  anechoic 
chamber  in  the  world  as  shown  in  Figure  2.  It  measures  264  x  250  x  70  feet  and  can 
accommodate  virtually  any  existing  military  aircraft.  The  Radar  Absorbent  Material  (RAM), 
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shielding,  and  free-space  volume  provide  an  ideal  test  environment,  free  from  interference,  with 
repeatable  test  conditions.  It  includes  an  80  foot  diameter  turntable  which  can  rotate  over 


Figure  2  -  Benefield  Anechoic  Chamber 


250,000  pounds,  ±190°,  with  0.05°  resolution.  This  enables  DF  and  sector  crossover  testing  of 
the  installed  system  in  a  controlled  environment.  Untold  hours  of  flight  testing  can  be  eliminated 
by  judicious  use  of  the  BAF. 

The  third  solution  is  to  develop  a  “walkaround”  aircraft  tester.  This  can  range  from  a 
formal  piece  of  flight  line  test  equipment,  to  an  informal  cart  full  of  laboratory  test  equipment 
and  an  extension  cord.  While  the  aircraft  is  on  the  flight  line,  DF  can  be  evaluated  on  the  installed 
system  by  radiating  from  the  cart  to  the  aircraft  from  previously  marked  angle  positions.  This 
enables  limited  DF  troubleshooting  under  static,  but  installed  conditions.  The  set-up  is  less  than 
perfect,  since  there  can  be  multipath  from  the  ground  or  nearby  structures.  However,  careful 
selection  of  location,  coupled  with  a  few  panels  of  RF  absorber  material  scattered  on  the  ground 
between  the  cart  and  the  aircraft,  can  all  but  eliminate  the  potential  interference.  A  fringe  benefit 
of  such  a  test  set-up  is  that  it  can  be  used  for  a  confidence  check  prior  to  each  flight  test.  Before 
takeoff,  the  installed  system  can  be  verified  to  be  receiving  and  transmitting  properly,  before 
costly  flight  test  assets  are  committed.  It  was  the  assembly  of  such  a  walkaround  test  cart  that 
enabled  the  diagnosis  and  fix  of  the  aforementioned  B-52  DF  blanking  problem. 

3.0  RANGE  ISSUES 

In  order  to  evaluate  Electronic  Warfare  performance,  specialized  test  ranges  are  required. 
These  have  the  necessary  threats  and  threat  simulators,  as  well  as  physical  security  to  enable 
uncompromised  classified  testing.  Due  to  the  assets  and  physical  spaces  required,  there  are  a 
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limited  number  of  ranges  available.  As  unique  as  each  is,  they  all  tend  to  suffer  from  the  same 
issues,  driven  by  threats,  scenarios,  multipath,  and  new  threat  assets. 


3.1  Threats 

The  categories  of  threats  that  are  typically  encountered  during  EW  flight  testing  include: 
Surrogates  -  Friendly  systems  used  in  place  of  real  threats 
Simulators  -  US  build  replicas  of  real  threats 
Real  Threats  -  Actual  threat  systems 

Each  of  these  have  potential  problems  which  must  be  addressed. 

EW  systems  are  usually  designed  against  a  formal  list  of  threats  defined  at  the  start  of  the 
program.  These  threat  parameters  are  used  to  define  threat  identification  tables,  algorithms,  etc. 
Although  the  EW  systems  are  reprogrammable,  the  baseline  programs  are  based  on  the  defined 
threat  data.  If  the  systems  encountered  during  testing  are  not  consistent  with  the  real  threat  data, 
the  EW  system  will  not  be  able  to  perform  properly,  and  test  results  can  be  severely  impacted. 

Surrogates  by  their  very  nature  are  not  likely  to  match  the  real  threats  in  all  categories. 
They  may  have  parameters  outside  the  real  threat  ranges,  waveforms  different  from  the  real 
threat,  or  modes  different  from  the  real  threat.  Even  when  these  are  identified,  they  can  be 
difficult  to  solve.  An  EW  flight  test  was  run  using  an  F-106  as  a  surrogate  for  a  Soviet  fighter. 
The  F-106  radar  had  a  PRI  modulation  not  present  in  the  real  threat,  therefore  the  PRI 
modulation  circuit  was  disabled.  The  EW  system  detected  modulation  and  made  the  wrong 
identification  (ID).  The  EW  system  engineer  met  with  the  radar  manufacturer’s  representative, 
who  showed  the  schematics,  and  the  capacitor  which  coupled  the  modulation  which  he  said  he 
removed.  Out  of  frustration,  the  EW  system  engineer  requested  the  removal  of  the  radar  unit 
from  the  aircraft  for  inspection.  Luckily,  the  field  rep  was  not  insulted  by  the  request  and  did  so. 
The  radar  unit  was  opened  on  the  radar  test  bench,  and  sure  enough  the  capacitor  was  removed. 
Power  was  hooked  up  to  the  unit  so  the  circuit  output  could  be  seen.  The  capacitor  was 
replaced,  and  the  PRI  circuit  exhibited  the  modulation.  The  capacitor  was  then  removed  and  the 
PRI  exhibited  more  modulation  than  before!  Since  there  had  never  been  a  need  to  remove  the 
modulation,  the  underlying  signal  had  probably  never  been  examined  before.  With  a  simple 
modification  the  circuit  was  connected  to  a  crystal,  creating  a  PRI  signal  which  matched  the 
threat.  From  then  on,  the  EW  system  ID’d  perfectly.  Only  because  a  junior  engineer  was  naive 
enough  to  ask  to  see  for  himself,  and  a  senior  field  rep  was  kind  enough  to  indulge,  was  this 
problem  discovered  and  fixed.  (I  am  to  this  day  grateful  to  him.) 

Simulators  may  not  match  the  real  threats  because  they  may  have  been  built  using  older 
threat  data,  using  current  data  but  from  a  different  intelligence  source  than  the  EW  program  data, 
or  they  may  have  been  modified  since  original  design.  Even  real  threats  may  not  match  program 
data,  since  the  threat  systems  may  be  aligned  to  extremes  or  have  substitute  repair  parts  which 
create  signals  outside  the  defined  ranges.  Simulator  and  threat  alignment  has  often  been  a  problem 
for  EW  system  testing.  In  at  least  two  cases  of  real  threats  ERI  has  been  involved  with,  the 
alignment  procedures  developed  by  the  US  operators  went  far  beyond  the  radar  manual 
instructions.  Both  examples  had  defined  alignment  procedures  which  were  difficult  to  implement 
and  could  drift  with  time.  They  were  replaced  with  new  procedures  which  were  really  only 
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applicable  to  test  conditions  and  could  not  have  been  used  in  the  field,  but  significantly  increased 
the  radars  resistance  to  jamming.  This  put  the  EW  systems  at  an  artificial  disadvantage  during 
testing  against  these  two  threats.  Even  worse,  in  both  cases  it  was  EW  engineers  who  showed 
the  radar  operators  how  to  better  align  the  systems!  As  Pogo  said  -  we  have  met  the  enemy  and 
he  is  us. 

The  solution  to  all  of  the  above  potential  problems  is  the  same  -  measure  and  verify  each 
threat  system  on  the  test  range  that  the  EW  system  will  encounter.  This  requires  getting  portable 
equipment  into  the  field,  to  measure  and  record  all  critical  parameters,  such  as  frequency,  PRI, 
jitter,  pulse  width,  etc.  The  recorded  data  can  then  be  used  to  program  signal  generators  in  the 
laboratoiy  in  order  to  test  the  EW  system  with  the  test  range  threats.  The  EW  system  can  then 
be  modified  for  operation  with  the  test  threats.  This  may  include  reprogramming  threat  ID 
tables,  modifying  threat  lists,  and/or  adding  a  TEST  mode  for  test  range  threats  only. 

3.2  Scenario 

Most  EW  tests  are  planned  to  include  a  limited  number  of  threats  at  any  given  time. 
Figure  3  illustrates  a  typical  planned  scenario.  This  enables  easier  interpretation  of  results  when 
initially  working  one-on-one,  and  holds  down  range  costs.  After  the  individual  tests,  one-on- 
many  tests  are  run  to  ensure  operation  in  a  realistic  environment. 


The  potential  problem  is  that  the  range  assets  are  not  always  totally  controlled.  Test 
sites  may  be  transmitting  for  maintenance  or  calibration.  Operators  may  want  to  track  a  target  of 
opportunity  for  practice.  If  the  aircraft  is  a  low  observable  (LO)  vehicle,  it  is  very  tempting  for 
an  operator  to  try  to  detect  it.  Another  possibility  is  that  there  may  be  other  tests  going  on 
within  the  radar  horizon.  Even  large  test  ranges  have  limited  airspace,  and  there  are  usually  co¬ 
located  or  nearby  bases  flying  routine  training  missions.  ERI  has  found  that  at  a  typical  EW  test 
range  like  Eglin  Air  Force  Base  there  are  always  F-15s  flying  nearby,  creating  a  nearly  continuous 
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high  pulse  density  background.  Again,  in  the  case  of  an  LO  vehicle,  there  is  the  additional 
temptation  for  them  to  try  to  find  and  track  it.  The  bottom  line,  is  that  despite  the  best  of 
intentions,  the  scenarios  encountered  are  usually  outside  the  test  plan  as  shown  in  Figure  4. 
This  can  impact  the  testing  by  tying  up  limited  EW  system  resources  on  non-test  signals  and 
which  can  bump  test  threats  from  limited  EW  system  resources,  resulting  in  a  form  of  unexpected 
interference. 


Figure  4  -  Typical  test  scenario  encountered 


The  solution  to  scenario  issues  is  similar  to  the  threat  issues  -  identify  the  potential 
problems  and  solve  them  in  the  lab  before  getting  to  the  test  range.  Identify  all  the  threats  on  the 
test  range,  to  provide  definition  of  possible  unintended  signals  which  may  be  encountered  during 
testing.  This  includes  ground  assets  and  locations,  airborne  assets,  and  nearby  air  and  naval 
assets.  Then  program  the  laboratory  signal  generators  with  the  potential  unintended  signals. 
Layout  the  ground  sites  the  same  as  they  are  on  the  range  and  add  in  a  mix  of  on-  and  off-range 
airborne  signals.  This  will  enable  evaluation  of  the  worst  case  likely  to  be  seen  on  the  test  range. 

3.3  Multipath 

Another  form  of  unintended  signal  corruption  possible  during  flight  test  is  multipath. 
During  low  altitude  flights,  both  received  and  transmitted  signals  can  be  reflected  off  the  ground 
and  added  to  the  direct  path  signal.  This  distorts  the  signals  in  both  directions,  by  adding  time 
varying  amplitude  and  phase  modulation,  and  stretching  the  pulse  width.  This  can  impact  threat 
identification  and  jamming.  Pulse  width  threat  ID  can  be  affected,  and  any  retrodirective  jamming 
techniques  can  be  corrupted  by  the  multipath  AM  and  PM.  In  early  B-1A  monopulse  EW  flight 
tests  conducted  by  ERI  personnel  at  200  feet,  the  effects  of  multipath  were  disastrous.  It  took 
multiple  flights  to  solve  the  problems.  Fast  forward  15  years,  and  a  B-52  EW  flight  test  at  500 
feet  suffered  many  similar  problems.  ERI  was  called  in  to  assist,  and  not  surprisingly,  the  same 
solutions  installed  in  the  B-1A  EW  system,  were  implemented  in  the  B-52  EW  system,  and  the 
multipath  problems  were  again  solved.  Despite  the  reputation  of  B-l  EW,  it  saved  the  day  for 
the  B-52. 
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Since  multipath  is  a  physical  phenomenon,  it  cannot  be  eliminated.  If  required  to  fly  at 
low  altitude  in  the  real  world,  the  EW  system  must  be  able  to  work  in  the  presence  of  multipath. 
The  solution  is  to  simulate  multipath  effects  in  the  laboratory.  The  effect  can  be  calculated  for 
the  planned  flight  geometry.  Multipath  can  be  created  in  the  lab  by  coupling  a  sample  of  the 
signal  with  the  anticipated  delay  and  reflection  loss.  Adding  random  amplitude  and  phase 
modulations  increase  the  fidelity  of  the  multipath  simulation.  Typical  EW  system  modifications 
to  enable  operation  in  the  presence  of  multipath  include  adjusting  pulse  sampling  times,  adjusting 
measure  and  set  update  rates,  and  stretching  jam  pulses  to  cover  the  delayed  reflection. 


3.4  New  Assets 

One  problem  that  seems  to  reoccur  in  EW  testing  is  when  the  system  is  scheduled  to  be 
the  first  to  test  against  a  new  threat  asset.  Although  it  should  not  matter,  ERI  has  found  that  the 
first  test  against  a  new  asset  tends  to  be  very  inefficient.  There  is  usually  more  time  spent 
troubleshooting  the  threat  asset  than  testing  the  EW  system.  Additionally,  the  lack  of  a  threat 
performance  baseline  creates  difficulty  in  interpreting  results.  ERI’s  experience  dictates  that  the 
first  test  on  an  asset  always  takes  longer  than  planned. 

There  are  no  real  solutions  to  this  potential  problem,  but  there  is  a  way  to  minimize  its 
impact.  The  best  option  available  is  to  schedule  the  new  asset  at  the  end  of  the  EW  system  test 
sequence.  If  there  are  problems  with  new  asset,  the  impact  to  the  other  tests  is  minimized.  If  the 
test  cannot  be  completed  within  schedule,  it  will  likely  be  necessary  to  cancel  or  postpone  the 
new  asset  test.  If  postponed,  the  return  may  be  after  the  asset  has  matured,  eliminating  the 
problem. 


4.0  TEST  ISSUES 

Due  to  the  complex  nature  of  Electronic  Warfare  evaluation,  the  test  process  itself,  has 
many  issues.  These  include  EW  system  configuration,  operator  learning,  operator  cooperation, 
and  operator  observations. 

4.1  System  Configuration 

The  two  primary  potential  problems  are  the  risk  of  uncertainty  in  EW  system  parameter 
settings  and  multiple  EW  setting  changes  between  test  runs.  System  changes  are  often  made 
between  test  runs  in  order  to  maximize  the  amount  of  data  during  a  flight,  especially  during 
optimization  and  development  testing.  Under  short  time  and  intense  pressure,  it  is  easy  to  forget 
to  record  the  details.  This  can  later  cause  chaos  during  data  analysis,  when  it  may  be  difficult  to 
recreate  the  information.  This  creates  obvious  challenges  in  interpreting  the  test  data.  The 
second  problem  is  caused  by  changing  multiple  settings  between  runs.  If  performance  gets  better 
(or  worse)  it  is  difficult  to  determine  which  of  the  multiple  changes  (or  combination)  was  the 
cause. 

The  solutions  for  both  are  essentially  to  adhere  to  the  discipline  of  good  test  engineering 
practice.  In  order  to  insure  that  an  accurate  record  of  system  settings  and  events  is  recorded,  ERI 
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assigns  an  individual,  who  is  outside  the  decision  making  loop,  the  full  time  task  of  religiously 
recording  all  pertinent  data.  This  includes  start  and  stop  times  of  all  runs,  all  system  parameters 
for  each  run,  and  any  observations  or  contemporaneous  comments  made  by  any  participants. 
This  will  insure  a  complete  and  accurate  record  which  becomes  invaluable  during  data  analysis. 
In  order  to  prevent  ambiguous  results,  a  similarly  disciplined  approach  to  system  changes  is 
required.  ERI  assigns  the  final  say  for  real  time  changes  to  a  single  individual  for  consistency  and 
to  maintain  control  for  the  test  discipline.  He  is  tasked  to  limit  changes  to  a  single  parameter 
between  runs,  and  also  to  attempt  to  bracket  a  good  setting  to  establish  confidence  that  it  is 
optimum. 

4.2  Operator  Learning 

EW  versus  automatic  systems  is  a  waveform  versus  processing  battle,  which  typically 
provides  very  consistent  results.  If  it  works,  it  will  work  over  and  over  again.  EW  versus  a 
human  operator  is  more  a  battle  of  wits,  because  the  human  operator  learns  every  time  he  sees 
the  EW  waveform.  Since  the  effect  is  one  of  deception,  surprise  is  a  large  part  of  the  success.  If 
the  human  operator  is  given  enough  time,  eventually  he  can  discern  even  trivial  clues  which  he  can 
use  to  negate  the  deception.  For  example,  if  the  EW  system  uses  a  cover  pulse,  a  wide  noise 
pulse  to  cover  the  real  target  return,  it  can  prevent  accurate  range  tracking.  Additionally,  this  will 
create  a  situation  where  the  radar  angle  tracking  circuits  only  see  jamming,  with  no  aircraft  skin 
signal  (this  is  known  as  an  infinite  Jam-to-Signal  ratio),  enhancing  the  chances  of  angle  errors  or 
breaklock.  But  since  the  cover  pulse  frequency  will  not  be  exactly  the  same  as  the  radar 
frequency,  the  two  frequencies  will  beat  against  each  other,  creating  a  “birdie”  where  the  real 
target  is.  This  can  be  masked  but  not  eliminated.  Given  enough  time,  a  radar  operator  can 
eventually  learn  to  isolate  the  birdie.  Another  subtle  but  potentially  useful  cue  is  when  the 
baseline  lifts  slightly  under  a  false  target  which  covers  the  real  signal.  This  is  known  a  “the 
mouse  under  the  rug”. 

There  are  two  aspects  of  EW  testing  that  make  the  process  vulnerable  to  operator 
learning.  First,  although  simulation  and  analysis  can  direct  the  system  designer  towards  effective 
jamming  techniques,  the  final  optimization  requires  repetitive  runs  to  home  in  on  the  best 
waveforms.  This  can  give  the  operator  an  opportunity  to  observe  the  techniques  many  times, 
and  try  various  means  of  countering  them.  Although  an  operator  in  a  real  situation  would  only 
see  a  technique  once,  the  test  operator  has  multiple  opportunities  to  learn.  If  a  minor  cue  in  a 
technique  can  be  learned,  the  remaining  test  runs  can  result  in  zero  effectiveness.  This  can  clearly 
skew  test  results  in  an  unrealistic  and  unfavorable  manner.  Second,  the  statistical  requirements  to 
establish  confidence  in  the  test  data  require  multiple  runs  of  the  final  jamming  techniques.  This 
further  extends  the  operator  learning  opportunities,  but  can  also  present  a  situation  where  the 
aircraft  geometry  is  the  same  run  after  run.  Operators  learning  the  target  aircraft  location  can 
further  bias  the  test  results  against  the  EW  system. 

Operator  learning  can  never  be  totally  eliminated,  but  it  can  be  minimized.  The  first  step 
is  to  limit  operator  exposure  during  optimization  tests.  This  can  be  accomplished  by  utilizing  a 
limited  subset  of  available  techniques  during  the  optimization  phase,  ideally  the  lower  priority 
techniques.  When  the  data  testing  begins,  the  operator  will  be  faced  with  previously  unseen 
techniques.  To  minimize  operator  learning  during  the  data  runs,  techniques  with  some 
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randomness  should  be  employed.  For  example,  if  using  false  targets,  randomize  the  position  of 
the  real  target  from  run  to  run.  If  using  multiple  techniques  with  equivalent  effectiveness,  also 
randomize  selection  of  the  technique  for  each  engagement.  Finally,  plan  the  data  test  flights  so 
that  different  aircraft  geometries  are  interleaved  rather  than  running  one  geometiy  repetitively. 

4.3  Operator  Observations 

One  of  the  data  sources  available  during  EW  flight  testing  is  the  observation  of  the  threat 
operators,  both  ground  and  air.  However,  if  taken  as  gospel,  these  observations  can  create 
problems.  Operator  reports  may  favor  their  systems.  The  operators  have  pride  in  their  systems 
and  aircraft,  and  the  adversarial  nature  of  the  tests  stimulate  operators  competitiveness. 
Therefore,  operator  reports  are  susceptible  to  an  unintentional  bias  against  the  EW  system. 
Additionally,  the  best  jamming  techniques  are  surreptitious.  The  system  may  be  indicating  to  the 
operator  that  all  is  well,  when  it  really  isn’t.  For  example,  a  pilot  may  be  maintaining  a  steady 
track,  but  it  might  not  be  on  the  real  target.  There  are  many  examples  of  fighter  pilots  reporting 
“I  had  him  all  the  way  and  could  have  foxed  (fired  a  missile)  at  any  time”,  when  later  data 
analysis  indicated  it  was  a  side  lobe  lock  that  had  the  antenna  pointing  in  the  wrong  direction, 
where  a  missile  firing  would  only  have  resulted  in  a  wasted  missile. 

The  solution  to  these  potential  problems  is  threefold.  First,  verify  and  validate  all 
operator  observations  during  data  analysis.  If  the  data  confirms  the  observation,  the  confidence 
is  increased.  If  the  data  refutes  the  observation,  this  is  also  valuable  information,  since  it  can 
provide  insight  to  how  a  real  operator  will  interpret  the  jamming  effects.  Second,  deploy  test 
personnel  to  observe  at  radar  sites.  They  can  not  only  provide  independent  observations,  but 
can  also  learn  from  watching  the  displays  and  the  operator  actions.  For  airborne  threats,  the 
cockpit  displays  should  be  videotaped,  with  contemporaneous  comments  from  the  pilot  also 
recorded.  Third,  the  test  personnel  should  conduct  thorough  crew  debriefs.  Ask  about  specific 
cues  that  led  to  any  observations.  Get  as  much  detail  as  possible  to  understand  the  operators 
thought  processes  in  the  face  of  the  jamming. 


4.4  Operator  Cooperation 

EW  testing  often  uses  US  systems  as  surrogates  for  foreign  threats.  Generally  this 
requires  restricting  the  radar  system  operating  modes  which  are  beyond  the  real  threat  capability. 
This  can  tempt  operators  to  sneak  a  peek  at  the  forbidden  settings.  Being  human,  the  operators 
are  often  both  curious  and  competitive.  They  will  sometimes  try  a  restricted  setting,  especially  if 
the  jamming  is  successfully  defeating  the  limited  modes.  If  they  do  try,  they  often  won’t  admit 
to  it.  This  can  corrupt  optimization  and/or  data  collection. 

A  solution  that  ERI  has  employed  in  the  past  with  very  good  success  is  to  dedicate  one 
run  per  day  for  the  radar  operator.  For  that  run  he  is  allowed  unrestricted  free  play  for  his  radar. 
ERI  programmed  different  techniques  for  him  and  provided  assistance  analyzing  the  data.  This 
satisfied  all  operators  curiosity  and  competitiveness,  making  it  easy  for  them  to  stay  within  the 
restrictions  for  the  rest  of  the  test.  This  insured  valid  EW  data  collection,  and  provided  the  radar 
personnel  additional  useful  data.  It  is  a  win-win  approach  that  gets  everyone  on  the  same  team. 
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Unfortunately,  occasionally  the  competitive  urge  can  go  beyond  normal  behavior.  ERI 
was  involved  in  a  helicopter  EW  test  which  successfully  employed  many  of  the  operator  learning 
defenses  described  previously.  When  the  data  runs  started,  the  operators  were  caught  by 
surprise  and  the  EW  system  performed  very  effectively.  Apparently  the  lead  radar  operator 
assumed  nothing  could  beat  the  radar,  because  he  called  an  immediate  halt  to  the  test  so  he  could 
re-calibrate  the  radar.  After  calibration,  the  test  resumed  with  the  same  good  EW  system 
performance.  This  was  just  too  much  for  him.  He  opened  one  of  the  radar  system  drawers,  and 
started  adjusting  the  radar  servo  loop,  while  the  jamming  was  present,  dampening  the  response  to 
the  point  where  the  EW  system  could  no  longer  drive  the  radar  off  the  helicopter.  At  that 
setting,  the  radar  could  not  track  anything  but  a  slow  moving  helicopter  and  was  clearly  an 
egregious  violation  of  fairness  for  the  test.  The  Army  project  manager  witnessed  these  actions 
first  hand,  and  said  to  the  radar  operator  “you  can’t  do  that.”  He  replied,  “Lady,  it’s  my  radar,  I 
can  do  whatever  I  want.”  Fortunately  that  is  a  rare  occurrence,  but  it  highlights  the  extremes  of 
human  behavior  that  the  competitive  nature  of  EW  can  cause. 


5.0  DATA  ISSUES 

EW  tests  tend  to  generate  a  lot  of  data.  Very  often,  millisecond  type  events  must  be 
obtained  from  data  steams  running  for  minutes.  The  problems  stem  from  the  nature  of  the  data  - 
digital  rather  than  analog,  and  the  turnaround  time  required  to  reduce  the  data  for  analysis. 

5.1  Analog  vs.  Digital 

The  preponderance  of  data  generated  in  EW  flight  testing  is  digital.  All  EW  systems  are 
under  computer  control,  many  of  them  including  distributed  microprocessors.  Therefore, 
virtually  all  of  the  data  generated  is  digital.  Analyzing  digital  data  can  be  very  time  consuming.  It 
is  difficult  to  scan  thousands  of  lines  of  data  looking  for  correlated  events  without  automated 
routines.  The  high  sample  rates  are  required  to  capture  all  the  events,  producing  the  volumes  of 
data.  Lower  sampling  rates  could  reduce  the  amount  of  data,  but  at  the  risk  of  missing  significant 
events.  Alternatively,  analog  data  paints  a  picture  of  the  events,  enabling  rapid  insight  into 
events.  Figure  5  illustrates  the  advantages  of  analog  data  for  a  quick  “big  picture”  look  over 
digital  data. 
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Figure  5  -  Analog  versus  Digital  Data 

The  primary  solution  obviously  is  to  generate  analog  data.  This  can  be  done  at  the 
recording  site,  by  adding  analog  recording  channels  to  capture  critical  data  such  as  received  power 
level  (envelope  detector)  and  transmitted  power  for  each  jamming  channel.  Alternatively,  this 
can  be  produced  by  post-processing,  to  generate  analog  reports  from  recorded  digital  data. 
Having  key  data  in  analog  form  can  enable  quick  look  analyses  of  entire  runs  in  brief  scans.  The 
human  eye  and  brain  can  process  analog  data  virtually  instantly.  A  secondary  solution  is  to  filter 
the  digital  data  for  volume  reduction.  Collect  the  data  at  the  required  high  sampling  rate,  but  print 
out  only  when  selected  parameters  change.  This  will  eliminate  several  hundred  lines  of  identical 
data  which  must  be  carefully  scanned  to  find  a  single  parameter  change  which  may  be  meaningful. 

5.2  Turnaround  Time 

The  high  volume  and  complex  nature  of  EW  test  data  can  result  in  long  turnaround  times. 
In  the  worst  case,  it  can  exceed  the  time  between  flights.  During  optimization  or  troubleshooting 
efforts,  this  can  be  a  disaster.  Data  turnaround  times  can  reach  a  week,  while  flights  can  be 
scheduled  three  times  a  week.  It  is  difficult  to  plan  Monday’s  flight  when  the  previous  data 
arrives  Friday.  ERI  encountered  exactly  this  situation  during  a  B-52  EW  test.  Schedule  demands 
drove  the  test  to  3  flights  a  week,  but  the  data  reduction  facility  was  working  on  a  6  day 
turnaround. 

The  ideal  solution  is  to  interleave  threats  on  the  schedule,  so  a  given  threat  won’t  be 
repeated  until  after  the  previous  data  is  available.  However,  this  is  often  not  practical.  In  that 
case,  it  becomes  necessary  to  generate  critical  data  products  by  hand  from  immediately  available 
data.  Examples  include  hand  drawn  strip  charts  from  viewing  cockpit  videos,  and  hand  drawn 
strip  charts  from  unfiltered  on-board  digital  printouts.  These  can  be  correlated  via  time,  since  all 
recordings  include  a  common  range  clock,  usually  Greenwich  (Zulu)  time.  Although  this  is  not  a 
replacement  for  end  product  data  analysis,  it  can  provide  enough  insights  to  make  some  educated 
assessments  for  the  next  flight. 
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This  is  exactly  what  ERI  did  when  the  B-52  test  schedule  got  frantic.  F-15  cockpit 
videos  were  run  frame  by  frame,  and  significant  events  were  recorded  by  hand.  Figure  6 
illustrates  the  eclectic  mix  of  technologies  used  to  solve  this  problem. 


Figure  6  -  Technologies  employed  for  data  turn  around  solution 


The  video  radar  data  included  changes  in  velocity,  range,  azimuth,  or  elevation.  The 
digital  system  data  recorded  on  the  aircraft  was  printed  by  Boeing  as  soon  as  the  aircraft  landed 
and  overnight  expressed  to  the  test  range.  The  data  volume  had  been  reduced  by  the  selective 
print  out  technique,  and  was  analyzed  for  critical  events.  Finally,  strip  charts  were  manually 
created  from  the  two  data  sources.  The  alignment  of  the  data  from  the  two  sources  was  verified 
by  correlation  of  the  EW  velocity  jamming  and  the  F-15  velocity  readout.  It  provided  enough 
information  to  make  educated  decisions  for  the  successive  flights,  until  the  full  data  package  could 
be  reduced  and  analyzed. 

6.0  SUMMARY 

Electronic  Warfare  testing  provides  many  challenges  and  is  fraught  with  dangerous 
problems.  Fortunately,  many  known  problems  can  be  anticipated  and  avoided.  If  a  real  estate 
agent’s  secret  to  housing  is  “Location,  Location,  Location,”  ERI’s  secret  to  EW  testing  is  “Plan, 
Plan,  Plan.”  Yet  despite  the  best  laid  plans,  there  will  be  problems.  One  of  the  strangest  of  these 
involved  a  recent  helicopter  borne  EW  flight  test  at  Eglin.  A  couple  of  weeks  were  lost  due  to  an 
aircraft  accident.  The  helicopter  was  hit  while  it  was  parked  on  the  flight  line  -  by  a  lawnmower! 
Even  worse,  the  driver  couldn’t  be  arrested  -  he  was  already  a  prisoner  at  Eglin’s  Club  Fed! 

The  bottom  line  is  there  will  be  problems,  that  is  guaranteed.  However,  with  foresight 
and  planning,  at  least  they  won’t  be  the  same  old  familiar  problems. 
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Abstract: 


All  stockpile  reliability  management  concepts  are  based  on  a  model  of  the  performance  of  the  hardware 
under  storage  and  handling  conditions.  Due  to  recent  trends  in  technology,  the  stockpile  reliability 
manager  is  now  able  to  understand  what  series  of  environments  each  unit  has  encountered.  He  can  then 
apply  that  information  to  his  model  to  determine  more  accurately  what  amount  of  wearout  the  unit  has 
accrued,  and,  hence,  what  ‘life’  it  has  remaining. 

This  paper  discusses: 

1.  Various  methods  of  applying  environmental  sensing  and  data  recording  (ESDR). 

2.  Appropriate  levels  of  assembly  for  application  of  ESDR,  hardware  limitations  on  ESDR,  and  trades 
that  have  to  be  made  when  applying  ESDR. 

3.  How  ESDR  impacts  stockpile  reliability  management  processes  and  staffing. 

4.  How  recorded  information  can  be  applied  to  management  models 

5.  How  applying  ESDR  data  to  hardware  models  improves  stockpile  reliability  management. 
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1.0  Maintenance  Structures  Are  Predicated  On  Models  Of  The  Hardware 

All  maintenance  structures  are  based  on  a  model  of  how  the  hardware  to  be  supported 
reacts  to  the  various  environments  that  it  is  expected  to  encounter  while  in  storage  and  in 
use.  The  most  common  approach  to  stockpile  management  is  to  assume  that 
environments  are  evenly  spread  throughout  the  life  of  the  hardware  and  that  the  remaining 
time  to  wearout  and  disposal  has,  therefore,  a  linear  relationship  to  the  age  of  the 
hardware.  However,  the  amount  of  wearout  that  each  individual  item  within  a  stockpile 
has  incurred  is,  in  reality,  a  function  of  the  accumulation  of  stresses  induced  by 
environments  that  occur  randomly  during  the  usage  storage/profile  that  system  has  seen. 
By  sensing  and  recording  the  environmental  conditions  or  extremes  seen  by  each  stockpile 
element  and  applying  that  information  to  the  stress  model  of  that  system,  the  stockpile 
manager  can  determine  where  that  unit  is  in  its  designed  for  life.  Utilization  of 
environmental  data  in  this  manner  represents  a  significant  refinement  in  prognostic 
capability  for  the  stockpile  reliability  manager. 

2.0  General  Rules  Regarding  The  Application  of  ESDR 

Environmental  Sensing  and  Data  Recording  (ESDR)  can  be  applied  at  any  level  of 
assembly  within  a  system,  and  provides  the  capability  for  significant  improvements  in 
the  system’s  support  concept.  In  addition  to  providing  inputs  to  the  stockpile  manager’s 
data  engine,  ESDR  can  improve  the  overall  support  concept  by  providing  significant 
reduction  in  retest  Oks  (RTOKs).  This  is  made  possible  by  providing  the  stockpile 
manager  with  information  regarding  the  conditions  (environments)  under  which  failures 
have  occurred. 

Tailoring  ESDR  to  the  system  involves  trades  being  made  between  the  cost  and 
complexity  of  the  ESDR  hardware/software  and  the  burden  placed  on  the  support 
system.  Later  sections  of  this  paper  will  discuss  specific  trades  to  be  made  when 
applying  ESDR  at  various  levels  of  assembly.  ESDR  must  be  applied  using  the  following 
general  guidelines: 

•  The  decision  to  incorporate  ESDR  into  a  system’s  support  concept  must  be  made  on 
the  basis  of  the  optimization  of  life  cycle  cost.  There  will  be  an  increase  in  acquisition 
cost  associated  with  the  addition  of  ESDR  to  the  support  concept,  but  a  trade  must 
be  made  to  determine  if,  in  the  case  of  that  specific  system,  the  increase  in  acquisition 
cost  is  justified  by  the  improvements  in  system  support  costs,  operational 
availability,  etc. 
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•  ESDR  applied  at  any  assembly  level  must  be  capable  of  sensing  and  recording  , 
environmental  data  applicable  to  each  constituent  removable  item  from  that  level. 

This  information  need  not  be  sensed  at  the  lowest  level  of  assembly,  but  a  transfer 
function  must  be  available  from  the  point  of  sensing  to  the  removable  item.  That 
information  could  include  any  combination  of  the  following  environmental 
characteristics:  Temperature,  Temp.  Shock,  Vibration,  Humidity,  Power  Spectral 
Characteristics,  Stress/Strain,  Mechanical  Shock,  Coolant  Flow/Pressure,  etc. 

•  Data  recorded  by  ESDR  must  be  in  a  format  that  makes  it  applicable  to  the  model  of 
the  hardware,  within  the  limitations  imposed  by  the  installation.  In  some  cases,  a 
time  histogram  of  the  environments  experienced  is  necessary,  whereas  in  other  cases  it 
may  be  sufficient  to  simply  record  occurrences  of  periods  of  overstress. 

•  ESDR  hardware  must  be  inherently  higher  quality  than  that  of  the  hardware  which  it 
is  to  support.  That  is  because  it  must  operate  in  environments  that  the  supported 
hardware  must  only  survive  in  storage,  making  its  storage  and  operating  environments 
the  same. 

Environmental  Sensing  and  Data  Recording  is  most  commonly  a  microprocessor  based 
monolithic  device  incorporating,  as  a  minimum,  a  serial  digital  external  interface  for  data 
communication  and  control,  accelerometers  for  vibration/shock  sensing,  thermal  sensors, 
and  an  autonomous  power  supply. 

3.0  Application  Of  ESDR  At  Higher  Levels  Of  Assembly 

Addition  of  ESDR  at  the  highest  level  of  assembly  (the  system  level)  is  desirable  for  a 
number  of  reasons.  ESDR  can  most  easily  be  added  into  a  maintenance  structure  for 
systems  that  have  already  completed  design  and  are  soon  to  be  or  have  already  been 
fielded  at  the  higher  levels  of  assembly.  The  addition  of  ESDR  hardware  at  the  system 
level  requires  little  or  no  redesign  of  the  actual  system  hardware  if  the  system  is 
maintained  as  a  ‘wooden  round’  or  is  maintained  in  a  multiple  level  maintenance  concept. 
In  a  traditional  three  level  maintenance  structure,  system  maintenance  is  accomplished  by 
exchange  of  large  Line  Replaceable  Units  (LRUs),  made  up  of  smaller  assemblies  that  are 
repaired  at  depot  or  contractor  facilities.  Adding  ESDR  to  the  LRUs  is  usually  nothing 
more  than  adding  an  assembly  populated  with  a  single  self  contained  ESDR  capability  to 
each  LRU.  This  assembly  can  be  placed  into  system  real  estate  generally  devoted  to 
hardware  growth  capability. 
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Since  ESDR  hardware  stays  with  the  LRU  as  assemblies  are  removed  from  it  and 
replaced  by  other  ones  to  effect  LRU  repair,  utilizing  ESDR  at  these  high  levels  of 
assembly  places  additional  burden  on  the  support  system  to  track  the  accumulation  of 
stresses  and  wearout  experienced  by  each  assembly  as  it  moves  from  LRU  to  LRU. 
Addition  of  ESDR  to  the  system  level  does  not  come  without  a  cost,  however.  Batteries 
used  power  the  ESDR  package  to  allow  it  to  autonomously  sense  environmental 
conditions  must  be  recharged  or  replaced.  If  no  automatic  data  link  (either  physical  or  by 
radio)  is  mechanized  between  the  ESDR  and  a  stockpile  management  control  station,  the 
maintainer  must  periodically  visit  each  item  in  the  stockpile  and  download  the  data  to 
some  portable  media  for  transfer  to  the  control  station.  Both  of  these  represent  an 
effective  wearout  mechanism  for  the  hardware  that  did  not  originally  exist.  Additionally, 
the  cost  of  the  ESDR  hardware  (and  its  development)  represents  both  a  recurring  and  a 
non-recurring  cost  to  system  acquisition.  However,  the  cost  of  incorporating  ESDR  at 
the  system  level  is  offset  by  reduction  in  requirements  for  periodic  maintenance  that  come 
about  because  ESDR  has  been  incorporated  into  the  system.  For  instance,  ESDR  could 
be  utilized  to  sense  humidity  within  the  storage  container  and  transmit  that  information 
directly  to  the  control  station  on  a  periodic  basis.  This  function  would  effectively 
eliminate  the  need  for  a  maintainer  to  periodically  review  the  condition  of  the  storage 
container  by  looking  at  a  sight  glass.  A  residual  benefit  would  be  that  the  failed  item 
could  be  immediately  scheduled  for  corrective  action  a  soon  as  the  out  of  tolerance 
condition  was  encountered,  instead  of  the  unit  in  storage  being  subjected  to  the  out  of 
tolerance  condition  until  the  next  maintainer  visit  time  in  the  IRAN  cycle,  which  could  be 
a  significant  period  of  time.  This  would  serve  to  improve  the  quality  of  the  hardware  in 
stockpile,  effectively  improving  its  reliability  to  the  user  once  it  is  pulled  from  storage 
and  placed  into  use. 

3.1  Application  Of  ESDR  At  Higher  Levels  OF  Assembly  -  An  Example 

If,  for  instance,  we  determine  in  the  design  phase  that  the  wearout  of  a  hypothetical 
missile  system  is  primarily  a  function  of: 

•  The  intrusion  of  water  vapor  into  the  missile  container,  contaminating  the  motor 
propellant 

•  Delamination  of  the  propellant  due  to  vibration  and  shock. 

•  Failures  of  the  Guidance  Electronics  due  to  thermally  induced  stresses. 
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We  might  mechanize  an  ESDR  device,  tailored  to  the  application  that  incorporates  the 
following  features: 

1.  Batteiy  powered  unit,  internal  to  the  missile  container,  capable  of  sensing  humidity, 
incorporating  accelerometers  to  sense  shock  and  vibration,  temperature  sensor. 

2.  Since  humidity,  temperature,  and  vibrational  stresses  should  not  be  very  dynamic,  the 
unit  might  be  equipped  with  a  ‘sleep  mode’  and  ‘wake  up’  infrequently  to  sample  the 
environment.  Sampling  might  be  done  once  per  4  hours  if  diurnal  cycling  were 
determined  to  be  an  issue,  or  as  long  as  once  every  2  days  to  a  week  if  not.  This 
feature  would  serve  to  minimize  power  consumption  and  memory  utilization  for 
environmental  data  storage. 

3.  Since  shock  environments  are  random,  and  short-lived,  the  unit  might  be  equipped 
with  a  ‘wakeup’  circuit  that  is  low  power  and  provides  an  interrupt  stimulus  to  the 
ESDR  processor  to  wake  it  up  in  the  event  of  a  shock  event.  The  threshold  of  the 
wakeup  circuit  shock  sensor  must  be  set  such  that  the  processor  is  not  interrupted 
unless  the  wakeup  circuit  determines  that  he  shock  was  of  sufficient  energy  to  be 
catastrophic  in  nature.  A  second  wakeup  circuit  with  a  lower  threshold  would  be 
incorporated  into  the  ESDR  design  to  wake  up  the  processor  in  the  event  of  detected 
vibrational  or  shock  environments  that  are  not  considered  catastrophic. 

Items  2  and  3  would  be  incorporated  to  minimize  power  consumption  and  maximize 
battery  life  without  compromising  data  fidelity. 

4.0  Pros/Cons  Of  ESDR  at  The  LRI  Level 

The  most  effective  utilization  of  ESDR  is  at  the  lowest  repairable  level  of  assembly. 
However,  addition  of  ESDR  hardware  to  this  level  of  assembly  requires  that  the  ESDR 
hardware  be  incorporated  into  the  system  from  the  onset  of  the  design  process  in  an 
integrated  approach.  ESDR  incorporation  into  the  Lowest  Repairable  Item  (LRI)  does 
not  significantly  affect  the  ability  to  record  pertinent  environmental  data  and  associate  it 
with  the  lower  level  assemblies.  However,  adding  ESDR  provides  new  functionality  that 
serves  to  optimize  the  overall  maintenance  concept,  thereby  reducing  0  &  S  costs.  A 
microprocessor  based  device  installed  on  the  LRI  can  be  modified  to  incorporate  PI  149.1 
or  other  testability  interfaces  to  allow  the  ESDR  device  to  participate  directly  in  the  BIT 
architecture.  This  dual  use  capability  minimizes  the  real  estate  cost  of  the  incorporation 
of  the  ESDR  into  the  LRI  by  making  it  into  an  effective  replacement  for  BIT  related 
hardware.  Additionally,  the  ESDR  can  be  utilized  as  a  repository  for  BIT  test  results  as 
well  as  environmental  data,  both  of  which  can  be  operated  on  by  an  expert  system 
external  to  the  LRI/LRU  (in  a  portable  maintenance  aid,  for  instance)  to  effect  significant 
RTOK  reduction.  This  serves  to  reduce  the  burden  on  the  support  system  as  well  as 
improving  system  availability  to  the  user  directly. 
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Figure  4.3-1  shows  a  sample  hardware  data  log  contained  in  ESDR  hardware  installed  on  a 
line  replaceable  item.  In  this  case,  LRI  fault  logging  devices  are  slaved  to  a  system  master 
processor  (referred  to  as  the  OBD,  or  on-board  diagnostic  computer)when  the  LRI  is 
installed  into  its  host  system.  Data  entry  is  made  into  the  fault  logging  device  non¬ 
volatile  storage  at  all  levels  of  assembly.  First,  the  depot  or  manufacturer  makes  an  entiy 
into  the  fault  log  to  provide  it  with  serialization,  part  number,  revision  codes,  etc., 
generally  via  Special  Inspection  test  equipment  used  to  test/diagnose  the  LRIs  health. 

The  LRI  identification  information  is  programmable  because  the  LRI  that  hosts  the 
ESDR  hardware  may  be  programmable,  and  the  part  number/revision  code  may  be 
dependent  on  software  load.  Accumulated  run  time  is  stored  into  each  LRI  fault  log  as 
part  of  the  system  shutdown  sequence,  by  the  system  OBD  processor.  The  last  entry 
made  into  the  LRI  identification  block  is  a  pointer  into  Non-Volatile  Memory  (NVM), 
identifying  where  the  maintenance  record  blocks  are  to  be  found.  Each  Maintenance 
record  block  in  the  NVM,  then,  contains  a  pointer  identifying  where  the  last  fault  log 
block  related  to  it  can  be  found.  The  maintenance  data  block  also  contains  information 
relating  to  the  installation  of  the  host  LRI  into  the  system.  This  information  can  be  used 
to  diagnose  faults  that  are  installation  related  (i.e.,  faulty  connectors  on  the  rack,  faulty 
cooling,  etc.).  In  this  example,  fault  logs  can  be  instantiated  by  a  number  of  different 
avenues.  First,  the  system  OBD  processor  will  insert  a  fault  log  into  any  LRIs  that  are 
suspect  in  a  particular  system  performance  failure.  Second,  the  system  OBD  processor 
will  insert  a  fault  log  into  an  LRI  whenever  an  out  of  tolerance  environmental  condition 
exists  in  that  LRI.  For  instance,  the  OBD  processor  would  update  the  fault  log  of  all 
LRIs  in  the  system  if  it  determined  that  an  acceleration  or  vibration  overstress  had 
occurred,  whereas  only  a  specific  LRI  fault  log  would  be  updated  if  that  LRI  had 
overtemped  due  to  low  coolant  flow  through  it.  Third,  the  operator  (pilot)  could  update 
all  of  the  LRI  fault  logs  (it  would  overtax  the  operator  to  have  to  select  specific  fault  logs 
to  update),  by  switch  action,  if  he  felt  that  there  was  anomalous  system  behavior,  either 
environmentally  related,  or  not.  The  fault  log  is  time  tagged  to  allow  the  information  to  be 
related  to  system  telemetry  gathered  by  some  other  means,  by  correlating  the  telemetry  to 
the  switch  action  that  instantiated  the  fault  log. 
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One  advantage  of  including  ESDR  into  the  organizational  maintenance  concept  is  that  the 
maintenance  log  is  carried  along  with  the  LRI  to  every  maintenance  level.  If,  then,  an  LRI 
is  removed  at  the  organizational  level,  due  to  a  failure  that  is  induced  by  the  environmental 
conditions  that  the  system  is  being  subjected  to  at  the  time  of  the  failure,  and  returned  to 
a  repair  facility,  the  repair  facility  is  afforded  the  advantage  of  the  knowledge  of  what  that 
environment  was.  That  information  could  then  be  utilized  to  stimulate  the  LRI  to  failure 
by  replicating  the  environment  in  some  manner  after  the  UUT  RTOKs  without  the 
stimulus  applied.  This,  then,  ensures  higher  quality  stock  being  returned  to  the  stockpile. 
Another  benefit  of  incorporating  ESDR  at  this  level  of  assembly  and  making  it  interactive 
with  the  on  board  diagnostic  capability  is  a  reduction  in  the  number  of  LRIs  that  are 
returned  to  the  repair  facility  only  to  RTOK.  This  is  because  the  maintenance  processor 
in  the  system,  upon  determining  that  a  failure  has  occurred  that  involves  more  than  one 
LRI  (ambiguity)  can  annotate  each  LRI  as  having  a  ‘possible  failure’.  An  off  board  expert 
system  could  then  be  brought  to  bear  to  determine,  based  on  each  LRIs  failure  history, 
which  is  the  best  candidate  for  removal.  For  instance,  if  three  LRIs  are  suspect  in  a 
specific  system  failure,  the  PMA  (Portable  Maintenance  Aid)  expert  system  could  search 
each  LRI’s  failure  log  and  adjust  its  estimate  of  the  likelihood  of  any  LRI  being  the  failed 
unit,  based  on  a  determination  that  any  of  the  three  had  been  marked  as  ‘possibly  failed’ 
for  a  previous  similar  failure. 
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When  Is 


Word 

Description 

Entry  Made 

Source 

ID  Block 

1-2 

Part  Number 

Production 

Assembly/Rework 

3 

Revision  Code 

Production 

Assembly/Rework 

4-5 

Serial  Number 

Production 

Assembly/Rework 

6 

Accumulated  Run  Time 

At  End  Of  Each 

BIT 

7 

Series  Pointer 

Mission 

Production 

Assembly/Rework 

Maintenance 

Record  Block 

1 

A/C  Tail  Number 

On  R/R  Action 

PMA 

2 

Rack  Locator  Reference 

On  R/R  Action 

PMA 

3 

Slot  Location  W/I  Rack 

On  R/R  Action 

PMA 

4-5 

Date  Of  Installation 

On  R/R  Action 

PMA 

6-7 

Maintainer  I.D. 

On  R/R  Action 

PMA 

8 

Local  Fault  Pointer 

On  Fault 

BIT 

Fault  Los  Block 

1-2 

Date  Code 

On  Fault 

BIT 

3-4 

Time  Stamp 

On  Fault 

BIT 

5-8 

Environmental  Data 

On  Fault 

BIT 

9-lOus 

BIT  Data 

On  Fault 

BIT 

Table  4.1.1.3-1.  LRM  Fault  Log  Format 
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The  costs  of  adding  ESDR  to  the  lower  levels  of  assembly  are  similar,  but,  due  to  the  fact 
that  the  capability  is  distributed  throughout  the  system  rather  than  centralized  to  a  single 
monitoring  and  data  storage  device,  the  costs  are  increased  as  a  function  of  the  number  of 
LRIs  that  comprise  the  system.  Also,  the  ESDR  device  imposes  a  burden  on  the 
maintenance  concept  at  all  levels  of  assembly  That  is,  the  battery  power  that  allows 
ESDR  to  sense  environments  when  uninstalled  (when  the  LRI  is  in  storage)  now 
represents  a  wearout  at  both  the  organizational  as  well  as  depot  level.  This  burden  must 
be  accounted  for  in  both  the  O-level  and  depot  level  IRAN  cycles. 

If  ESDR  is  incorporated  into  the  on  board  diagnostic  (OBD)  design,  one  additional 
problem  that  the  designer  is  presented  with  is  a  result  of  the  ESDR  hardware  being 
mounted  on  unique  hardware  assemblies.  That  is,  BIT  software  incorporating  test 
vectors  for  the  LRI  on  which  the  ESDR  package  is  to  be  mounted  must  be  unique  to  the 
assembly  hosting  the  ESDR  package.  This  would  result  in  each  ESDR  package  being  a 
unique  part  number,  resulting  from  the  unique  vectors  residing  in  its  non-volatile  memory. 
One  approach  to  dealing  with  this  problem  is  to  allow  the  ESDR  processors  to 
communicate  via  a  digital  bus  (PI  149.1,  etc.),  each  slaved  to  a  master  diagnostic  processor 
in  the  system  The  ESDR  is  then  only  equipped  with  a  Kernel  that  allows  it  to  be  slaved 
to  the  OBD  master  and  accept  test  vectors  via  the  bus. 

4.1  Utilization  of  ESDR  at  Lower  Assembly  Levels  -  An  Example 

If  we  were  to  install  an  ESDR  package  on  each  LRM,  similar  to  the  ESDR  unit  described 
above,  what  would  be  the  benefits?  The  costs? 

First,  implementation  of  an  expert  system  to  operate  on  the  maintenance  history 
information  would  result  in  reduction  of  RTOKs  at  the  test  and  repair  facility.  This 
would  unburden  not  only  the  maintenance  and  repair  facility,  but  would  also  result  in 
reduced  loading  on  transportation  and  handling  facilities. 

Second,  since  the  maintenance  history  of  the  assemblies  storage  is  distributed  within  the 
assemblies  themselves,  the  cost  of  providing  centralized  support  system  computing  data 
storage  is  reduced  Additionally,  since  the  data  is  distributed  with  the  hardware,  any 
expert  system  software  used  to  operate  on  that  data  is  made  portable,  thereby  reducing 
demands  on  the  support  system  further. 

Third,  using  the  on-assembly  stored  environmental  data  as  described  in  the  previous 
chapters  to  identify  environmentally  induced  failures  will  further  reduce  the  demands  on 
the  support  system  in  general. 
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Now,  what  does  adding  the  ESDR  capability  to  a  system  cost?  If,  as  was  previously 
stated,  the  decision  to  include  ESDR  in  a  system  design  is  based  on  the  Life  Cycle  Cost 
impact,  it  should  be  readily  seen  that  the  trade  is  between  system  acquisition  cost  and  the 
savings  in  support  system  acquisition  cost.  If  now  year  and  then  year  cost  adjustments 
are  made.  Then  the  trade  generally  becomes  one  of  acquisition  cost  for  the  system  (due, 
primarily,  to  the  cost  of  the  ESDR  hardware  itself)  vs.  acquisition  cost  for  the  support 
system  (i.e.,  computing  power,  trucks,  test  equipment  ,etc.). 


5.0  Making  use  of  ESDR  Environmental  Data 

The  primaiy  use  of  ESDR  environmental  data  is  to  determine  the  accrued  damage  that  has 
been  incurred  by  the  item  in  storage/use  throughout  its  life.  For  the  purposes  of  this 
discussion,  we  will  assume  that  the  ESDR  data  recording  capability  is  carried  on  the 
lowest  replaceable  unit  at  the  organizational  level  (such  as  would  be  the  case  if  ESDR 
were  associated  with  a  ‘wooden  round’  missile. 

Application  of  ESDR  data  and  hardware  life  modeling  requires  that  the  hardware  be 
characterized  for  its  reaction  to  the  various  environmental  stimuli  that  are  expected  to  be 
encountered  in  the  system  design  life.  This  is  best  done  in  the  design  phase,  and  is 
generally  an  output  of  mechanical  design  of  the  system.  Modeling  done  in  the  mechanical 
design  will  give  the  designers  (and,  later,  the  maintenance  manager)  a  tool  to  predict  how 
the  hardware  reacts  to  temperature  and  vibration.  This  information  can  be  confirmed  in 
any  accelerated  life  testing  done  as  part  of  qualification  testing  of  the  system,  and  then 
applied  to  the  life  model  of  the  system.  In  our  example,  we  will  assume  that  humidity 
can  contribute  to  degradation  in  the  system  life  characteristics.  However,  since  our  ESDR 
design  for  the  support  system  includes  appropriate  humidity  sensing  and  alarm  capability 
(and,  hence,  any  occurrence  of  out  of  tolerance  humidity  in  storage  will  be  corrected 
promptly),  the  wearout  model  for  the  system  will  include  only  effects  of  temperature  and 
vibration/shock. 
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The  dynamic  model  for  most  systems  is  not  predicated  on  the  effects  of  the  system 
transitioning  through  a  range  of  temperatures  and  not  the  specific  minimums  and 
maximums  of  those  temperature  swings.  One  approach  to  obtaining  pertinent 
environmental  data  and  minimize  ESDR  processor  activity  has  been  to  equip  the  ESDR 
hardware  with  sample  and  hold  circuitry  that  is  always  enabled  and  which  senses  the 
‘turnaround’  temperatures  of  a  temperature  swing  (the  point  at  which  a  rising  temp  swing 
turns  to  a  lowering  swing  (or  a  maximum),  or  visa  versa).  At  the  transition  time,  an 
interrupt  is  generated  to  ‘wake  up’  the  ESDR  processor  which  then  determines  the 
temperature  range  by  subtracting  the  minimum  previously  identified  from  the  maximum 
most  recently  measured  at  the  turnaround.  The  processor  then  increments  a  counter  in 
the  appropriate  ‘bin’.  When  the  maintenance  manager  then  queries  the  ESDR  data  log,  he 
then  has  at  his  disposal  a  pictogram  of  how  many  excursions  the  hardware  has  seen  of 
each  temperature  range.  Each  ‘bin’  is  associated  with  a  different  life  acceleration  factor  as 
relating  to  the  initial  dynamic  model,  thereby  identifying  how  much  ‘life’  has  been  lost, 
due  to  the  quantity  and  range  of  thermal  excursions  experienced  by  the  hardware. 

In  a  similar  manner,  a  threshold  level  is  determined,  below  which  high  cycle  fatigue 
(vibrational  or  shock  stresses)  are  considered  to  have  ‘little  or  no  effect’.  The 
accelerometer  package  associated  with  the  ESDR  hardware  is  then  equipped  with  a 
thresholding  circuit  used  to  ‘wake  up’  the  ESDR  processor  if  the  threshold  is  exceeded. 
The  ESDR  processor  will  then  perform  appropriate  processing  on  the  raw  accelerometer 
data  to  identify  which  frequencies  of  vibration  are  above  the  threshold  level  and  by  how 
much.  The  processor  then  ‘bins’  the  data  in  a  manner  similar  to  temperature  data 
discussed  above,  except  that  the  bins  are  a  function  of  frequency  content  and  G  level. 
Additionally,  the  processor  must  determine  the  amount  of  time  that  the  environment  was 
encountered,  and  increment  the  record  for  that  frequency  and  G  level  with  the  duration  of 
the  excursion. 
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5.0  ESDR  and  warranty 


The  inclusion  of  ESDR  into  the  stockpile  management  process  provides  some  interesting 
possibilities  in  the  development  and  administration  of  system  warranties,  all  of  which 
should  result  in  lower  warranty  cost  at  acquisition  time. 

First,  incorporation  of  ESDR  into  the  system  support  concept  allows  the  contractor  to 
consider  a  ‘mileage’  clause  in  the  warranty  contract.  This  means  that  the  contractor  no 
longer  would  bear  sole  risk  that  the  system  will  be  used  in  the  ‘ideal’  manner  described  in 
the  system  specification.  Currently,  the  contractor  must  cost  the  warranty  assuming  that 
a  high  percentage  of  systems  warranted  will  be  used  in  accordance  with  the  environmental 
specifications,  but  that  some  number  of  units  will  be  used  for  training,  evaluation  or  other 
non-tactical  functions,  and,  hence,  will  experience  ‘accelerated’  wearout.  The  contractor 
cannot  design  in  additional  durability  to  accommodate  these  non-representative  usage 
scenarios  without  adding  significantly  to  acquisition  cost,  and  is  left  with  upscaling  the 
cost  of  the  warranty,  or  adding  specific,  sometimes  extreme,  exclusion  clauses  to  the 
warranty  contract.  By  allowing  the  assessment  of  wearout  incurred  in  these  non-ideal 
environments  and  adding  appropriate  wording  to  the  warranty  contract,  the  warranty  can 
be  tailored  appropriately. 

The  benefits  of  utilizing  ESDR  in  relation  to  warranty  administration  are  not  uniquely 
with  the  user,  however.  The  contractor  in  afforded  the  ability  to  void  the  warranty  on  a 
specific  system  if  it  is  significantly  mishandled  (dropped  by  a  maintainer,  etc.) ,  or 
misused,  such  as  would  be  the  case  if  a  specific  system  was  used  in  training  scenarios 
when  the  projected  usage  environment  for  the  ‘fleet’  showed  limited  deployed  use.  An 
example  of  this  would  be  missiles,  which  are,  essentially,  ‘one  shot’  devices.  In  this  case, 
a  warranty  would  have  to  be  negotiated  that  designated  some  number  of  missiles  as  ‘for 
training  use’  and  either  excluded  them  from  warranty  applicability,  or  made  special 
provisions  for  warranty  costing  of  those  items.  Again,  the  dynamic  model  of  the 
hardware,  and  projected  usage  profiles  for  the  training  aircraft  would  be  employed  to 
determine  the  ‘rate  of  wearout’  and  provide  the  contractor  with  a  basis  for  cost 
estimation. 
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ESDR  Aids  All  Levels  Of  Repair 


ESDR  Aids  In  Breaking  Ambiguity  Groups 

If  Function  ‘X’  Is  Distributed  Across  LRIs  As  Illustrated 
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Advanced  Built  in  Test  Equipment 


UTILIZING  SIMULATIONS  FOR  PERFORMING 
DEGRADATION  TREND  ANALYSES 


Eric  E  Hunt,  CRE 
Product  Assurance  Directorate 
U.S.  Army  Aviation  and  Missile  Command 
Redstone  Arsenal,  AL 

ABSTRACT 

The  process  of  modifying  a  simulations  model  for  supporting  stockpile  reliability 
program  (SRP)  analyses  of  a  tactical  missile  system  is  described.  Basic  application  of  the 
modified  simulation  to  SRP  analyses  is  discussed.  A  methodology  for  supporting  degradation 
trend  analyses  by  predicting  future  performance  is  developed.  Examples  from  an  ongoing 
analysis  are  provided.  It  is  shown  that  this  is  a  valuable  tool  with  significant  growth  potential. 
Model  programming  and  system  design  considerations  that  should  be  incorporated  early  in 
program  development  in  order  to  optimize  future  applications  of  the  methodology  are  discussed. 


INTRODUCTION 

Missile  systems  are  originally  procured  with  a  predicted  shelf  life.  After  fielding,  system 
data  is  analyzed  to  assess  the  original  shelf  life  prediction  and  perform  shelf  life  extensions 
whenever  possible  and  necessary.  This  Army  program  is  referred  to  as  the  Stockpile  Reliability 
Program  (SRP).  Historically,  Army  missile  systems  have  been  procured  with  an  average  seven- 
year  shelf  life,  however,  through  the  SRP  the  shelf  life  has  been  extended  to  an  average  of  18 
years.  SRP  utilizes  a  variety  of  test  methodologies  and  analysis  techniques  customized  to  each 
missile  system.  In  general,  data  is  collected  over  the  life  of  the  missile  system  from  surveillance 
(field  storage  and  operations),  flight  testing,  and  disassembly/component  testing.  This  data  is 
then  analyzed  for  trends  associated  with  age,  manufacturing  strata,  and  exposure  environments. 
Undesirable  trends  may  result  in  suspension,  restriction,  or  risk  acceptance.  When  the  system 
continues  to  perform  reliably  and  safely,  and  still  meets  a  tactical  need  (i.e.,  is  not  obsolete,  or 
replaced  by  a  new  system) ,  then  a  shelf  life  extension  will  be  coordinated  with  the  Army  missile 
community.  For  obvious  reasons  this  program  attains  high  visibility.  For  example,  extending  a 
system’s  shelf  life  may  have  a  significant  impact  on  the  decision  to  procure  a  replacement 
system.  Shelf  life  extensions  must  be  taken  seriously,  with  the  greatest  possible  statistical 
confidence  imposed.  Unfortunately,  due  to  significant  operating  budget  shortfalls,  the  Army 
SRP  is  extremely  constrained.  Accordingly,  several  new  initiatives  have  been  undertaken  in  SRP 
to  improve  the  confidence  of  the  analyses  at  equivalent  or  reduced  costs.  One  of  these  initiatives 
is  to  extend  the  use  of  simulation  models  created  during  system  development  for  assessing  and 
predicting  missile  system  shelf  life. 


Specifically,  this  paper  reflects  efforts  associated  to  the  HELLFIRE  SRP.  The 
HELLFIRE  SRP  utilizes  an  annual  sample  of  15  HELLFIRE  missiles  for  disassembly  and 
component  testing,  and  21  missiles  biennially  for  flight  testing.  In  general,  all  of  the  samples  are 
selected  from  dedicated  assets.  These  are  missiles  that  were  sampled  across  production  and  set 
aside  specifically  for  SRP  testing.  HELLFIRE  model  AGM-114A  (PA79)  and  AGM-114C 
(PD68)  missiles  were  sampled,  starting  in  1985,  with  a  total  of  487  dedicated  assets  assembled 
by  1989.  These  missiles  were  electronically  all-up-round  (AUR)  tested  and  then  placed  in 
carport  type  structures  in  Alaska,  Arizona,  and  Panama.  These  structures  expose  the  missiles  to 
the  environment  while  not  subjecting  them  to  direct  precipitation  or  solar  loading.  The  missiles 
eire  maintained  in  their  original  shipping  containers  IAW  the  HELLFIRE  Supply  Bulletin  (SB) 
742-1425-92-010.  The  Army  HELLFIRE  SRP  was  designed  to  promote  natural  accelerated  aging 
(within  the  specified  storage  limits)  in  order  to  project  future  stockpile  performance  by 
identifying  trends  in  the  dedicated  assets  prior  to  their  occurrence  in  the  stockpile.  In  addition, 
samples  may  be  selected  from  the  field  for  special  tests.  For  example,  a  total  of  48  missiles  were 
sampled  from  the  Operation  Desert  Storm  retrograde.  Twenty  of  these  missiles  have  been  flight 
tested,  and  14  of  these  were  disassembled  and  component  tested. 

After  performing  HELLFIRE  SRP  sample  selection,  the  missiles  are  shipped  to  the 
Redstone  Technical  Test  Center  (RTTC),  Redstone  Arsenal,  Alabama.  The  RTTC  provides 
AUR  testing,  X-ray,  disassembly,  and  component  functional  testing.  Propellant  samples  are 
provided  for  chemical  and  mechanical  analyses.  Missiles  selected  for  flight  testing  are  provided 
to  Eglin  Air  Force  Base  after  the  completion  of  AUR  testing  and  X-ray  at  RTTC. 

A  total  of  206  SRP  missiles  have  been  tested  since  1990,  with  120  missiles  being  component 
tested  and  86  being  flight  tested.  It  should  be  noted  that  there  are  additional  sources  of  data  that 
are  monitored  for  trends,  e.g.,  malfunction  reports,  ammunition  condition  reports,  quality 
deficiency  reports,  etc.  Additionally,  surveillance  vans  perform  non-destructive  electronic  testing 
of  the  dedicated  assets  and  other  samples  from  the  inventory  annually.  The  surveillance  van 
measures  126  electronic  parameters,  and  is  the  source  of  over  20,000  missile  tests. 

Until  1993  there  was  no  capability  to  analyze  the  extensive  amount  of  data  that  had  been 
collected  on  the  electronic  components.  These  components  have  numerous  performance 
parameters  that  can  be  tested  at  several  environmental  conditions  without  destroying  the 
component,  thereby  producing  a  large  amount  of  data.  A  high  priority  was  placed  on  loading  this 
data  into  a  system  that  could  be  accessed,  downloaded,  and  then  analyzed  using  a  desktop 
personal  computer.  This  effort  was  completed  in  December  1993  and  currently  contains  over 
three  gigabits  of  SRP  and  surveillance  data. 

Generally,  SRP  analysis  involves  plotting  parameter  data  versus  age  at  the  time  of  test, 
then  performing  curve  fitting  to  identify  parameters  that  display  statistically  significant  trends. 
An  example  of  this  type  of  analysis  is  shown  in  figure  1.  When  a  trend  is  identified,  the 
reliability  engineer  is  confronted  with  the  task  of  determining  what  affect  (if  any)  the  trend  will 
have  on  the  missile  system’s  reliability,  safety  or  performance.  This  is  often  not  an  exact 


science.  Parameter  specifications  were  often  the  result  of  engineering  judgment  to  begin  with,  and 
the  actual  point  of  mission  affecting  failure  could  be  at  the  specification  limit,  or  far  outside  it. 
Additionally,  the  combined  affect  of  multiple  minor  trends,  for  which  the  individual  parameters 
approach  the  limits  but  do  not  exceed  them,  cannot  be  evaluated  through  this  traditional  trend 
analyses  technique. 
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Figure  1.  Example  of  traditional  SRP  trend  analysis.  (Note:  Data  not  to  be  construed  as 

actual) 


MODIFICATION  OF  THE  SIMULATIONS  MODEL 

A  six-degree-of-freedom  (6-DOF)  simulations  model  known  as  the  Laser  Designator 
Weapon  System  Simulation  (LDWSS)  was  originally  developed  to  support  development  and 
production  of  the  HELLFIRE  missile.  The  LDWSS  runs  a  multiple  number  of  trials  per  scenario 
in  a  Monte  Carlo  fashion.  It  can  output  various  plots  such  as  trajectory  and  miss  distance.  The 
system  calculates  circular  error  probability  and  probability  of  hit. 

After  the  electronic  component  SRP  data  was  successfully  transferred  to  database  we 
identified  the  need  to  find  a  better  method  for  analyzing  the  large  amount  of  data.  We  also 


became  aware  of  it’s  significant  potential  for  simulations  applications.  Based  on  consensual 
identification  of  this  need,  several  agencies  teamed  to  modify  and  validate  the  original  LDWSS 
model  for  this  application.  The  approach  was  to  initially  bring  the  simulations  personnel 
together  with  the  test  personnel.  The  test  personnel  provided  background  information  to  the 
simulations  personnel  on  all  testing  and  parameter  readings  taken  during  SRP  tests.  With  this 
information,  the  simulations  personnel  were  able  to  identify  which  of  the  parameters  could  be 
applied  directly  to  the  existing  LDWSS  model,  and  which  could  be  applied  through  minor 
modifications  to  the  model.  Then,  in  a  team  effort  between  system  engineers,  SRP  analysts 
(reliability  engineers),  and  simulations  personnel,  optimum  areas  for  modification  of  the  LDWSS 
model  were  selected.  For  example,  if  a  modification  could  be  made  to  allow  entiy  of  a  specific 
parameter,  but  it  was  identified  by  the  system  engineer  that  the  parameter  would  have 
insignificant  impact  on  system  performance,  or  it  was  determined  by  the  SRP  analyst  that  the 
parameter  would  be  unlikely  to  change  with  age,  that  modification  might  not  be  performed  in  lieu 
of  other  more  critical.  Modifications  were  performed  in  the  seeker,  control  section  and  autopilot 
models.  Additionally,  a  simple  model,  which  did  not  exist  previously,  was  developed  for  the 
thermal  battery  and  integrated  with  LDWSS. 

In  the  process  of  this  development,  it  was  realized  that  the  original  means  and 
distributions  for  the  parameters  used  in  the  LDWSS  were  not  necessarily  reflective  of  the 
readings  actually  being  measured  in  SRP  testing  of  the  inventory.  This  should  not  have  been  a 
surprise,  since  the  means  and  distributions  were  based  on  the  specification  requirements, 
combined  with  engineering  analyses  of  what  distribution  would  be  expected  for  each  parameter. 
No  known  “follow-on”  attempt  to  analyze  data  on  actual  production  hardware  in  order  to  re¬ 
calculate  means  and  distributions  had  ever  been  performed.  Using  the  SRP  database  the 
simulations  personnel  developed  more  realistic  means  and  distributions  for  all  available 
parameters  based  on  actual  data  collected  on  0-4  year  old  missiles.  This  became  a  significant,  yet 
initially  unplanned  modification  to  the  simulations  model.  After  reviewing  the  planned 
modifications  with  all  members  of  the  development  team,  the  simulations  personnel  performed  a 
validation-verification  utilizing  available  flight  test  data.  Effort  was  then  shifted  to  the 
application  of  the  model. 


BASIC  APPLICATION  METHODOLOGY 

When  the  exemplaiy  work  to  modify  the  model  was  completed,  the  reliability  engineer 
became  involved  in  determining  how  the  simulation  would  be  applied.  It  was  quickly  apparent 
that  the  other  personnel  on  the  team  had  their  own  ideas  of  how  to  apply  the  model,  and  at  that 
time,  we  had  insufficient  funding  to  further  influence  the  effort.  Emphasis  was  therefore  placed 
on  performing  applications  of  interest  to  the  systems  engineers.  These  analyses  would  be  the 
most  likely  to  have  an  immediate  impact  on  the  ongoing  production  of  follow-on  models  of  the 
HELLFIRE  missile. 


Component  testing  of  SRP  assets  has  often  identified  failures  of  items  for  specific  test 
parameters.  The  systems  engineers  believed  that  most  of  these  “failures”  would  have  little  or  no 
impact  on  system  performance.  In  general,  this  became  the  basis  for  utilizing  the  simulation  to 
“re-build”  a  missile  from  it’s  component  test  results.  For  example,  even  if  a  missile  failed  to  meet 
a  specification  parameter,  how  would  it  have  performed  if  actually  flown?  Therefore,  the 
direction  by  the  systems  engineers  was  to  ”re-assemble”  missiles  from  their  component  data,  and 
“fly  them”  in  the  simulation.  The  next  step  was  to  identify  appropriate  flight  test  scenarios. 
Working  with  test  engineering  and  a  seeker  technical  expert,  20  flight  scenarios  that  were  believed 
to  represent  “edge  of  the  envelope”  performance  were  selected.  These  vary  in  range,  offset  angle, 
flight  mode,  and  designation  delay.  For  two  years,  all  of  the  component  data  for  each  SRP 
missile  sampled  (15/yr,  30  total)  was  plugged  in  to  the  model  to  simulate  how  the  missile  would 
have  performed  if  it  had  been  flown  at  each  of  the  20  scenarios.  It  was  decided  through  limited 
engineering  analysis  that  5000  run-sets  for  each  scenario  would  be  used.  This  was  considered  a 
large  enough  sample  to  support  statistic  statements.  “Rebuilding  missiles”  in  the  simulation  was 
not  without  merit.  For  example,  one  control  section  failure  that  previously  was  believed  would 
not  affect  system  flight,  was  identified  to  affect  probability  of  hit  under  specific  scenarios. 

Under  previous  methodologies,  we  would  have  concluded  that  this  missile  would  not  have  been 
affected  by  the  minor  failure.  Using  the  simulation,  it  was  discovered  that  the  missile  would  have 
had  significant  reductions  in  the  probability  of  hit  under  some  flight  scenarios.  Discovering  this, 
even  on  only  one  of  30  missiles  analyzed,  was  a  significant  advance  in  SRP  analysis. 

Recall  the  original  objective  of  the  SRP  program,  “to  predict  the  future  performance  of 
missile  systems”.  It  is  apparent  that  this  re-building  of  missiles  in  the  simulation  has  limited 
value  for  satisfying  this  need.  However,  we  could  now  report  something  to  the  effect  that  “if 
these  15  missiles,  ranging  in  age  from  x  to  y  years  were  flown  in  this  scenario,  z%  would  have  hit 
the  target.”  This  was  an  improvement.  We  could  “fly”  an  SRP  missile  over-and-over  under 
numerous  scenarios  after  it  had  been  re-created  in  the  simulation,  but  it  is  clear  that  there  is  room 
for  additional  application  methodologies. 


DEGRADATION  TREND  ANALYSIS  METHODOLOGY 

Generally,  most  persons  involved  in  the  project  only  identified  with  the  capability  to 
calculate  probability  of  hit  for  missiles  of  various  ages.  They  felt  that  trend  analyses  could  then 
be  performed  on  the  relationship  between  probability  of  hit  versus  age.  Unfortunately  this 
provides  no  significant  improvement  to  SRP  analyses.  Based  on  the  missiles  being  spread  across 
various  ages,  combined  with  the  fact  that  missiles  could  not  be  re-built  in  the  simulation  if  one 
component  experienced  a  hard  failure,  this  methodology  yielded  a  veiy  small,  loosely  distributed 
sample  set.  An  example  of  this  methodology  being  applied  is  demonstrated  in  figure  2.  These 
analyses  exhibited  very  low  statistical  confidence.  Additionally,  it  took  no  advantage  of  the 
extensive  amount  of  test  data  collected  on  the  inventory  utilizing  the  surveillance  van. 


As  stated  previously,  there  are  two  significant  shortfalls  with  the  traditional  method  of 
SRP  analysis  based  on  individual  parameter  degradation  trends.  One  is  that  it  is  often  difficult  to 
determine  the  point  at  which  a  trend  will  affect  the  missile  mission.  The  other  is  that  it  is 
impossible  to  evaluate  when  a  combination  of  minor  trends  will  affect  the  missile  mission.  We 
needed  to  develop  a  new 


Figure  2.  Example  of  probability  of  hit  based  trend  analysis.  (Note:  Data  not  to  be  construed 
_ _ as  actual) _ 

approach  for  application  of  the  simulation.  The  new  methodology  identified  is  simply  an 
extension  of  the  current  trend  analysis  process  into  simulations.  This  method  optimizes  the 
available  SRP  data,  and  eliminates  the  shortfalls  of  the  traditional  method.  Utilizing  the 
HELLFIRE  SRP  database,  thousands  of  readings  taken  on  many  of  the  electronic  parameters  is 
plotted  versus  age  for  trend  analysis.  The  large  number  of  readings  provide  trend  analyses  of 
high  confidence.  Figure  3  provides  an  example  of  one  of  these  trend  analyses  for  three  to  ten  year 
old  missiles.  The  fitted  line  is  projected  out  as  a  prediction  of  the  performance  of  this  parameter 
in  the  future.  This  analysis  is  performed  on  hundreds  of  individual  parameters.  Other  than  being 
able  to  now  utilize  the  significant  amount  of  data  being  entered  into  the  SRP  database,  this  is  the 
same  as  the  traditional  method  of  SRP  analysis.  The  next  step  is  the  new  approach.  Using  figure 


3  as  an  example,  we  extract  a  predicted  mean  and  distribution  for  this  parameter  at  15  years. 
This  same  “extraction”  can  be  performed  from  all  of 


Dais  Points 


the  individual  parameters  trend  analyses.  The  extracted  parameter  means  and  distributions  are 
simultaneously  input  to  the  simulation,  “building-up”  the  predicted  model  for  a  15  year-old 
missile.  This  model  can  be  run  through  5000  run-sets  for  each  of  the  standard  20  flight  scenarios. 
This  effort  utilizes  all  available  test  data,  identifies  actual  missile  performance  impacts  of  all 
parameter  trends  combined,  and  predicts  future  performance. 


LIMITATIONS  OF  PERFORMANCE  PREDICTION 

Utilizing  this  new  method  does  not  eliminate  limitations  associated  to  the  traditional 
process  of  performing  degradation  trend  analyses  of  individual  parameters.  That  is,  the 
mathematics  of  plotting  the  data  and  applying  a  best-fit  line  for  predictions  is  the  same.  This 
process  is  subject  to  difficulties  in  determining  that  trends  are  actual  age  degradation,  and  not 
associated  to  some  change  in  test  methodology,  sample  population,  etc.  Additionally,  this 


process  does  not  identify  the  mechanism  behind  the  trend,  which  should  be  determined  in  order 
to  validate  the  prediction. 

There  are  also  some  parameters  for  which  trends  or  failures  cannot  be  analyzed  well  using 
the  HELLFIRE  simulation.  Generally  this  includes  all  of  the  “one-shot”  components  (thermal 
battery,  gyroscopes,  accumulator/  regulator,  rocket  motor,  warhead,  and  S&A).  Some  of  these 
devices  have  no/limited  modeling  fidelity  in  the  simulation.  For  example,  in  the  case  of  the 
thermal  batteries,  there  was  no  modeling  in  the  original  simulation.  A  voltage  level  at  which  the 
missile  fails  hard  was  identified  in  laboratory  testing.  The  improvement  to  the  model  was 
basically  to  create  a  “truncation”  point  for  a  simulated  flight  when  the  battery  falls  below  that 
minimum  level.  This  is  a  crude  model  since  the  power  requirements  and  usage  can  be  affected 
significantly  by  a  variety  of  factors.  Some  of  the  one-shot  components  are  treated  in  the 
simulation  as  go/no-go.  For  example,  either  the  fuze  arms  or  it  doesn’t.  All  of  these  one-shot 
items  still  require  traditional  SRP  analyses. 

There  is  not  a  developed  methodology  for  the  determination  of  distributions  to  be  applied 
to  the  predicted  values.  Look  at  the  point  where  the  15-year  predicted  value  was  extracted  from 
the  fitted  line  in  figure  3.  We  could  utilize  the  prediction  lines  at  that  age  to  determine  standard 
deviation  for  a  normal  distribution  around  that  predicted  mean  point.  Although  the  use  of 
prediction  lines  beyond  the  data  set  is  mathematically  inappropriate,  the  expanding  lines  do 
represent  some  level  of  increasing  uncertainty  in  the  prediction.  Another  method  is  to  utilize  the 
current  distribution  determined  for  each  parameter  and  apply  that  distribution  around  the 
extracted  value.  Neither  of  these  methods  is  considered  to  be  the  best  solution  and  there  is  room 
for  further  development  in  this  area. 


CONSIDERATIONS  FOR  PROGRAMMING  AND  SYSTEM  DESIGN 

One  result  of  the  activities  described  herein  is  increased  knowledge  of  how  the  simulations 
model  should  be  designed  for  life  cycle  use.  The  fidelity  of  the  model  is  critical.  Subsystems 
should  be  modeled  to  their  subcomponents,  and  the  subcomponents  to  each  independent  output. 
This  is  obviously  difficult  early  in  the  design,  and  requires  close  integration  of  the  simulations 
and  engineering  activities.  Continuous  changes  to  the  model  will  occur  as  the  design  is  solidified. 
Additionally,  the  simulation  should  be  revisited  after  full  rate  production  to  verify  that  means 
and  distributions  are  representative  of  actual  hardware  being  produced. 

Alternatively,  specific  considerations  should  be  taken  into  account  for  the  design  of  the 
hardware.  The  methodology  becomes  more  powerful  if  a  greater  number  of  performance  affecting 
parameters  can  be  non-destructively  measured  and  input  to  the  simulation  model.  Thus,  the 
hardware  should  be  designed  for  testability.  The  extensive  use  of  missile  hardware-in-the-loop 
(HWIL)  testing  in  modem  systems  has  indirectly  resulted  in  significant  contributions  to  this 
objective.  HWIL  testability  requires  access  to  critical  data  streams,  and  high  fidelity  simulation 
models. 


SUMMARY 


Depending  on  the  fidelity  of  the  original  simulations  model,  the  process  described  herein 
can  be  utilized  to  effectively  develop  the  model  for  life  cycle  uses.  However,  the  best  case  would 
be  to  plan  for,  and  develop  the  model  for  this  application  early  in  program  development.  Proper 
development  of  the  model  for  this  use  requires  the  teamwork  of  personnel  from  a  variety  of 
disciplines,  to  include  simulations,  reliability,  systems,  and  test.  Combining  traditional  SRP 
trend  analysis  with  simulations  provides  a  new  capability  to  predict  future  performance,  and  has 
significant  potential  for  growth  into  other  life  cycle  applications. 
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A  PC-Based  Visual  Munition  Simulation  System  Using  VisSim 


by  Larry  E.  Lewis 
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Eglin  Air  Force  Base,  FL  32542  USA 

JAWS  Track:  Joint  SOS  -  SDT 


Abstract 

Development  of  technology  for  high  performance  missiles  and  bombs  is  becoming 
more  and  more  dependent  on  effective  simulations  to  provide  information  for  making  the 
best  technology  investments  and  to  provide  insights  into  potential  performance  of 
munitions  incorporating  such  technology.  With  dollars  and  manpower  in  an  ever 
decreasing  spiral,  it  is  more  critical  than  ever  to  have  available  effective,  easy  to  use 
simulations  that  can  be  rapidly  configured  to  provide  fast  answers.  Historically,  such 
simulations  have  been  cumbersome  and  difficult  to  modify.  Fortunately,  with  increasing 
computer  power  and  sophisticated  commercial  software  available  at  low  cost,  it  is 
becoming  more  possible  to  build  remarkably  effective  tools  within  available  budgets. 

As  part  of  the  MSTARS  (Munition  Simulation  Tools  And  Resources)  project  which 
supports  development  and  analysis  of  new  munition  technology,  a  modular  visual 
modeling  system  for  simulating  6  degree-of-freedom  (DOF)  munition  flyouts  has  been 
developed  using  the  commercial  tool  VisSim.  With  reusable  munition  subsystem  and 
other  components,  simulations  can  be  rapidly  built  to  test  new  ideas  using  both  single  and 
multiple  run  techniques.  This  paper  presents  the  key  elements  of  the  simulation  system  and 
discusses  the  impact  of  using  this  type  of  visual  system  on  the  simulation  &  analysis 
process. 


1.  Analysis  Requirements 

At  AFRL/MNGG,  we  are  responsible  for  analysis  of  conceptual  next  generation  guided 
munitions  and  the  new  technologies  that  will  feed  them.  This  analysis  includes 

•  Determination  of  performance  requirements 

•  Design  tradeoff  studies  to  identify  high  payoff  munition  concepts 

•  Technology  tradeoff  studies  to  identify  which  technologies  will  represent  the  best 
investments 

•  Identification  of  critical  issues  associated  with  munition  concepts  and  technologies. 

The  ultimate  purpose  of  MNGG  analysis  is  to  insure  that  the  limited  funding  available 
for  research  and  development  goes  to  the  highest  payoff  technologies,  and  that  those 


technologies  transition  as  quickly  as  possible  into  the  inventory  of  available  weapons  to 
help  the  warfighter. 

To  meet  these  requirements,  a  variety  of  analysis  approaches  are  used.  These  range 
from  back-of-the-envelope  calculations  to  sophisticated  simulations.  In  the  analysis  of 
guided  weapons,  dynamic  simulations  of  weapon  flight  paths,  or  flyouts,  are  critical. 
Simple  3-DOF  point  mass  simulations  can  answer  many  questions  in  the  initial  concept 
formulation  phases,  such  as  basic  flight  characteristics  and  gross  performance  potential. 
As  concept  formulation  and  evaluation  continues,  more  fidelity  is  needed  to  generate 
accurate  trajectories,  determine  better  values  for  maximum  velocity  and  range,  and  to 
conduct  analysis  of  possible  guidance  and  control  schemes.  This  is  a  job  for  the  6-DOF 
simulation. 


2.  Tool  Selection 

Traditionally,  6-DOF  simulations  have  been  very  labor  intensive.  Typically  developed 
in  a  higher  order  language  such  as  FORTRAN  or  Ada,  they  require  much  preparation  and 
debugging  time  because  the  source  code  environment  is  very  error-prone.  Also,  the  final 
product  is  neither  easily  modified  nor  intuitive.  Two  common  approaches  to  such 
traditional  simulations  are  to  either  start  from  scratch  to  build  a  new  simulation  for  every 
new  modeling  requirement  or  to  tiy  to  build  a  massive  "generic"  simulation  with  hundreds 
of  switches  and  options  to  tiy  to  do  everything  in  one  package.  Neither  choice  is  very 
appealing.  In  the  former  approach,  nothing  is  reused,  wasting  much  time  and  effort 
rebuilding  models,  not  to  mention  the  additional  wasted  time  and  effort  spent  in 
debugging.  In  the  latter  approach,  it  is  sometimes  possible  to  contrive  examples  for  which 
a  large  generic  simulation  is  useful,  but  more  often  than  not,  one  winds  up  making 
extensive  modifications  which  are  made  more  difficult  due  to  the  large  interconnected 
logic  of  the  switches  and  options  -  more  wasted  time. 

With  shrinking  budgets  and  personnel,  simulation  tools  are  desired  that  make  it 
possible  to  do  work  better,  with  fewer  people,  and  at  lower  cost.  Such  tools  should  be: 

•  Easy  to  use 

•  Easy  to  debug 

•  Capable  of  building  reusable  models 

•  Low  cost 

•  Intuitive 

•  Fast  executing 

•  Conducive  to  building  models  rapidly 

•  Flexible  in  handling  different  requirements 

•  Capable  of  handling  complexity 

•  Effective  in  reducing  errors 


In  recent  years,  there  has  been  a  move  to  visual  environments  for  many  software 
applications,  from  computer  aided  design  (CAD)  to  banking  programs.  In  the  scientific 
and  engineering  analysis  field,  these  include  visual  circuit  design  programs,  visual 
mathematics  programs,  and  visual  control  system  design  programs,  among  others.  The 
advantage  of  visual  tools  over  their  high  order  language  counterparts  is  that  they  meet 
more  of  the  key  requirements  listed  above,  except  that  they  are  more  expensive  and 
sometimes  have  less  flexibility  -  because  they  are  tailored  to  a  specific  problem  domain. 
However,  if  carefully  chosen  for  the  problem  domain  of  interest,  and  if  combined  with 
other  tools  (spreadsheets,  high  order  language  programs,  etc)  to  cover  areas  which  they 
can't  handle  as  well,  then  visual  analysis  tools  represent  the  very  best  environment  in 
which  to  do  analysis  work. 

For  6-DOF  simulation  requirements,  visual  control  system  design  programs  are  very 
attractive.  The  typical  weapon  system  is  comprised  of  a  large  number  of  systems  that  can 
be  represented  very  well  by  visual  construction  in  the  control  system  domain.  In  addition, 
modern  visual  control  system  design  applications  have  become  increasingly  sophisticated 
and  are  capable  of  handling  much  more  than  just  control  system  type  problems. 

There  are  many  excellent  visual  control  system  design  tools  from  which  to  choose. 
These  include  MATLAB/  Simulink  from  Mathworks,  MATRIXx/  System  Build  from 
Integrated  Systems,  Inc,  and  VisSim  from  Visual  Solutions,  among  many  others.  At 
AFRL/MNGG,  we  use  several  of  these  tools  in  our  work,  including  all  of  the  ones 
previously  mentioned.  Each  has  areas  in  which  it  is  clearly  superior  to  the  others  and  also 
areas  in  which  it  is  inferior  to  the  others.  For  our  6-DOF  simulation  work,  we  are 
interested  in  the  PC  environment  and  most  available  tools  today  support  this  environment. 
For  the  bulk  of  our  6-DOF  simulation  work,  we  chose  VisSim  because,  in  addition  to 
meeting  most  of  the  capability  requirements  on  our  wish  list  (as  did  the  other  tools) ,  it  is 
lower  in  cost,  easier  and  faster  to  use  for  this  job,  is  capable  of  standalone  operation  not 
requiring  a  "parent  environment",  and  has  a  nice  feature  for  sharing  simulation  models 
with  colleagues  and  customers  who  do  not  own  the  product  (a  special  viewer).  It  is 
capable  of  incorporating  external  models  developed  in  more  languages  than  most  tools 
allow  (C,  C++,  FORTRAN,  Ada  95,  and  Pascal),  which  makes  it  easier  for  us  to 
incorporate  existing  legacy  software  from  multiple  sources  and  makes  it  more  flexible  for 
other  organizations  which  work  with  us  to  interface  their  software  to  ours.  It  is  capable  of 
supporting  multiple  rate  continuous  integration  models  through  code  generation  of  model 
subsystems  to  create  DLLs  (Dynamic-Link  Libraries)  which  run  under  Windows. 

The  focus  of  this  paper  is  on  the  architecture  of  a  6-DOF  modeling  system  which  we 
have  built  using  VisSim.  The  paper  will  also  discuss  how  the  visual  environment  has 
transformed  the  way  in  which  we  work. 


3.  The  MSTARS  Simulation  System 

The  Munition  Simulation  Tools  and  Resources  (MSTARS)  project  is  a  low  budget  in- 
house  project  in  which  we  build  and  maintain  the  simulation  tools  needed  for  analysis  here 


at  MNGG.  Many  simulation  tools  are  used  at  MNGG,  including  a  large  number  of 
FORTRAN  simulations  and  a  couple  of  Ada  simulations.  For  reasons  cited  previously, 
there  was  a  desire  to  move  to  a  visual  environment  for  our  6-DOF  simulation  work. 

In  March  1997,  we  built  an  initial  prototype  6-DOF  simulation  using  VisSim,  and 
based  on  rationale  described  in  the  previous  section,  we  decided  to  use  VisSim  as  the 
environment  for  the  bulk  or  our  6-DOF  simulation  work.  Our  desire  was  to  meet  the 
analysis  requirements  identified  previously  and  also  to  build  a  work  environment 
conducive  to  good  team  participation. 

The  PC  was  chosen  as  the  computer  platform  for  the  MSTARS  system.  PCs  have 
become  so  inexpensive  and  powerful  in  recent  years  that  using  unix  workstations  for  our 
simulation  work  is  no  longer  cost  effective.  We  still  have  one  Sun  workstation  for  special 
purpose  work,  but  the  bulk  of  our  simulation  and  analysis  work  is  now  done  on  PCs.  Each 
engineer  in  the  team  has  a  266  MHz  Pentium  PC  and  there  is  a  standalone  200  MHz  PC 
which  serves  as  a  repository  for  the  MSTARS  simulation  component  library.  When  new 
models  are  developed  they  are  placed  on  the  standalone  PC  for  easy  retrieval  by  team 
members.  Simulation  runs  are  conducted  on  each  engineer's  PC,  allowing  much  parallel 
work  to  occur  without  slowing  down  the  simulations. 

The  modeling  system  which  has  evolved  over  the  past  year  is  called  the  MSTARS 
Simulation  System.  It  has  already  been  used  successfully  to  support  both  air-to-air  and  air- 
to-surface  munition  analysis,  and  is  constantly  being  upgraded  as  required  for  new  analysis 
needs. 

Some  important  features  of  the  MSTARS  Simulation  System  include: 

•  Top  level  simulation  diagram  with  easy  to  understand  bitmaps  for  component  access 

•  Modular  organization  of  component  library  in  Windows  directories 

•  Simulation  construction  in  hierarachical  levels 

•  Uniform  structure  for  component  layout 

•  Model  attribute  values  via  external  user  defined  file 

•  Model  documentation  built  into  the  diagrams 

•  Easy  swapping  &  modification  of  components 

•  External  DLLs  for  a  number  of  components 

•  Sample  attribute  files  for  each  model  component 

•  Various  data  file  save  options  for  analysis 

Section  4  describes  the  MSTARS  Simulation  System  architecture  in  more  detail, 
elaborating  on  several  key  features  of  the  system. 


4.  Basic  Architecture 


4.1.  Top  Level  Components 


In  the  MSTARS  Simulation  System,  any  number  of  different  air-to-air  or  air-to-surface 
simulations  can  be  built.  The  top  level  of  a  typical  MSTARS  simulation  is  shown  below  in 
Fig.  1.  At  this  level  are  found  the  primary  objects  in  the  simulation,  namely  the  munition, 
launch  aircraft,  and  threat.  It  also  includes  facilities  for  setup,  viewing  terminal  conditions, 
setting  environment  parameters,  and  viewing  plot  outputs.  These  objects  are  VisSim 
compound  blocks  which  have  appropriate  bitmap  images  assigned  to  them. 


Fig.  1.  Typical  Top  Level  Diagram  in  an  MSTARS  Simulation 


The  Launcher  is  a  launch  aircraft,  currently  modeled  as  having  an  initial  position  and 
velocity  with  no  maneuver  subsequent  to  launch.  Data  link  and  umbilical  models  can  be 
attached  to  the  aircraft  to  provide  these  functions  for  scenarios  which  need  them. 

The  threat  in  an  air-to-surface  scenario  is  either  a  fixed  or  moving  ground  target. 
Currently,  the  surface  target  models  just  provide  position  and  velocity  information  for  the 
target.  Future  upgrades  will  allow  for  IR  signatures  to  be  handled.  Air  targets  have  the 
same  information  plus  acceleration  definable  in  a  flexible  maneuver  model.  In  addition, 
aspect  dependent  statistical  and  deterministic  RF  target  signature  models  may  be  attached 
to  a  target  model.  Future  upgrades  will  add  IR  signatures  to  this  capability. 

Since  we  are  most  interested  in  munition  performance,  the  munition  object  (guided 
missile  or  bomb)  is  modeled  in  the  most  detail  and  will  be  described  in  the  next  section. 

The  Environment  model  at  the  top  level  is  a  global  environment  model  which  provides 
atmospheric  or  other  global  environment  conditions  for  use  by  other  simulation 
components.  Currently,  user  defined  air  pressure  is  the  only  parameter  provided  by  this 
model. 


The  Terminal  Conditions  block  provides  endgame  information  such  as  miss  vector, 
miss  distance,  terminal  velocity,  and  impact  angles.  These  parameters  differ  somewhat 
between  air-to-air  and  air-to-surface  simulations. 

The  Setup  block  reads  in  simulation  control  settings  (for  monte  carlo  runs)  and 
provides  a  simulation  clock  for  use  by  other  modules.  This  block  could  be  modified  to  add 
other  control  options  for  the  simulation  as  desired. 

The  Outputs  block  contains  numerous  plots  and  a  disk  output  facility.  A  number  of  plot 
boxes  have  been  created  for  several  standard  kinds  of  quick  look  assessments,  and  any 
number  of  new  ones  can  be  added  by  users  as  desired.  Typically,  each  simulation  will 
have  some  unique  plot  outputs.  An  example  is  shown  in  Fig.  2. 


Fig.  2.  Sample  plot  outputs 


4.2.  Munition  Model 


A  munition  model  is  designed  for  easy  swapping  of  components  for  fast  evaluation  of  new 
designs  and  algorithms.  The  top  level  of  a  typical  munition  model  built  using  MSTARS 
components  is  a  collection  of  icons  allowing  easy  component  access,  as  shown  below  in 
Fig.  3. 


Fig.  3.  Typical  Munition  Model 

Each  icon  represents  a  VisSim  compound  block  in  which  is  found  the  complete 
subsystem  model.  It  can  be  a  high  or  low  fidelity  model. 

The  munition  model  in  Fig.  3  can  be  used  to  illustrate  an  important  simulation  design 
choice  -  the  use  of  VisSim  global  and  scoped  variables  to  make  it  possible  to  replace 
subsystems  without  wire  connections.  A  VisSim  global  variable  can  be  seen  from  within 
any  diagram  at  any  level  in  a  simulation.  A  scoped  variable  can  be  seen  at  the  diagram 
level  where  it  is  defined  and  in  any  diagrams  contained  within  and  below  this  level.  Fig.  4 
shows  two  different  guidance  models.  These  would  be  visible  inside  the  G&C  icon  in  Fig. 
3.  Note  that  the  outputs  of  each  guidance  model  are  commanded  body  accelerations,  but 
the  inputs  required  by  the  two  models  are  somewhat  different.  Inputs  and  outputs  of  a 
model  at  the  level  just  below  the  munition  level  (Fig.  3)  are  accomplished  by  use  of  global 
variables.  This  means  that  one  can  swap  any  guidance  model  for  another  as  long  as  the 
required  inputs  are  calculated  somewhere  in  the  simulation.  Guidelines  for  global  names 
and  where  they  are  used  have  been  developed  for  the  simulation  system.  The  primary 
output  of  a  guidance  module  in  this  system  is  a  vector  containing  body  acceleration 
commands. 


Fig.  4.  Two  interchangeable  guidance  laws  in  MSTARS 


The  result  of  this  architecture  is  that  any  munition  subsystem  can  be  rapidly  swapped 
for  another.  Subsystem  models  or  the  entire  munition  model  can  be  swapped  out  by  either 
cut-and-paste  or  by  using  VisSim  Embed  blocks,  which  are  blocks  that  serve  as  pointers  to 
diagram  files.  The  latter  is  our  usual  method  in  the  MSTARS  Simulation  System.  The  use 
of  global  variables  should  be  minimized  because  there  is  a  potential  for  variable  name 
conflict  since  they  can  be  seen  anywhere  in  the  simulation.  For  this  reason,  models 
residing  at  lower  levels  in  the  MSTARS  hierarchy  are  designed  to  interface  with  wire 
connections  rather  than  global  variables. 

One  of  the  largest  issues  in  modeling  6-DOF  munitions  for  assessing  new  technology 
has  always  been  the  difficulty  in  modeling  aerodynamic  data  which  can  be  used  for 
conceptual  weapons  analysis.  Often,  there  is  no  wind  tunnel  data  available  because  a 
physical  model  does  not  exist.  In  addition,  there  is  usually  a  desire  to  make  physical 
changes  to  the  model  as  analysis  continues,  so  the  aerodynamic  coefficients  change  as 
well.  This  often  leads  to  autopilot  problems  because  autopilots  must  be  tuned  to  the 
aerodynamics.  The  problem  of  good  aerodymamic  data  is  not  one  for  which  there  is  an 
easy  solution.  We  have  used  a  widely  available  aerodynamic  modeling  program,  Missile 
DATCOM,  for  much  of  our  work  but  this  tool  is  not  suitable  for  all  desired  vehicle 
configurations.  However  the  MSTARS  Simulation  System  has  taken  two  steps  which 
make  the  general  problem  of  aerodynamic  modeling  a  bit  easier: 

•  Creation  of  a  standard  set  of  aerodynamic  coefficient  table  structures  so  that  any 
source  for  aerodynamic  data  can  be  put  into  a  common  format. 


Development  (still  in  progress)  of  aero-adaptive  autopilots  which  respond  to 
changes  in  aero  coefficents  during  a  simulation  without  re-tuning  (or  with  minimal 
re-tuning). 


4.3.  General  Component  Layout 

Designing  a  modeling  system  which  can  be  used  by  a  team  of  diverse  engineers  is  very 
challenging.  There  is  a  tradeoff  between  allowing  creativity  and  forcing  consistency. 

We've  chosen  a  middle  ground  where  model  consistency  is  good  but  not  too  limiting  on  the 
creative  process.  A  typical  subsystem  model,  a  control  surfaces  model,  is  shown  in  Fig.  5. 


Fig.  5.  Control  Surfaces  Model 


Several  characteristics  of  typical  MSTARS  model  layout  can  be  seen  in  Fig.  5: 

•  Title,  date,  and  version  number 

•  Model  description  block  containing  useful  model  information 

•  User-defined  model  attributes,  set  externally  and  wired  into  the  model.  This  allows 
attribute  setting  to  be  changed  without  affecting  the  ability  to  compile  the  diagram 
using  the  Visual  Solutions  C-code  generator 


Labeled  wire  connectors  where  needed 
Color  coded  comments  where  appropriate 
Vector  inputs  and  outputs  to  save  space 


The  Model  Description  block  in  Fig.  5  is  especially  important,  because  one  goal  of  the 
MSTARS  system  is  to  include  documentation  inside  the  model  to  the  extent  possible. 
Inside  the  description  block  are  comment  blocks  as  illustrated  in  Fig.  6. 
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Fig.  6.  Comments  included  in  Model  Description  block 


The  comment  blocks  provide  useful  information  such  as  author,  revision  history, 
inputs,  outputs,  attributes,  any  relevant  notes  and  references. 


4.4.  Data  I/O 

Data  input/  output  is  a  challenge  for  any  modeling  system.  Complex  flexible  data 
journaling  can  be  very  time  consuming.  We've  taken  a  simple  approach  in  the  MSTARS 
Simulation  System  which  is  fast,  yet  meets  most  normal  requirements  for  I/O.  It  will  be 
expanded  in  the  future  as  needed. 

Each  model  can  have  a  set  of  attributes  which  are  constant  for  a  simulation  run,  but  may 
change  from  run  to  run  and  from  run  set  to  run  set  if  Monte  Carlo  simulations  are  being 


executed.  In  the  MSTARS  Simulation  System,  this  is  accomplished  by  use  of  an  input  file 
containing  the  attribute  values  and  also  statistical  information  for  Monte  Carlo  simulations 
(see  section  4.5  for  more  information  on  how  Monte  Carlo  simulations  are  accomplished). 
The  input  file  is  read  by  a  special  C++  program  compiled  as  a  Windows  DLL.  Each 
component  information  block  has  a  special  identifier  and  can  be  placed  anywhere  in  the 
file.  Fig.  7  shows  a  sample  portion  of  a  simulation  input  file. 
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Fig.  7.  Portion  of  a  typical  input  file 

For  data  output,  a  combination  of  standard  VisSim  Export  blocks  and  external  DLLs 
are  used  to  accomplish  various  kinds  of  data  saves.  VisSim  Plot  blocks  are  used  for  quick- 
look  analysis  and  a  special  MSTARS  C++  DLL  saves  formatted  summary  information  for 
each  run  and  run  set.  Unformatted  ASCII  data,  arranged  in  columns,  is  saved  via  VisSim 
Export  blocks  for  loading  by  external  programs  such  as  MS  Excel,  or  a  number  of  lethality 
programs  which  analyze  warhead  effects  and  calculate  probability  of  kill  (Pj<). 


4.5.  Monte  Carlo  Simulations 

Monte  Carlo  simulations  are  extremely  important  for  many  problems  in  weapon 
analysis,  especially  for  generating  kinematic  footprints  (boundaries  of  air-to-surface 
munition  kinematic  flyout  range)  and  determining  miss  distance  statistics.  They  are  also 


important  in  identifying  cause  and  effect  relationships  between  design  parameters  and 
munition  performance. 

In  the  MSTARS  Simulation  System,  the  input  file  (Fig.  7)  contains  information 
necessary  for  conducting  Monte  Carlo  runs.  The  three  columns  of  data  in  the  input  file 
contain  the  parameters  for  each  model  attribute.  The  first  column  contains  the  nominal,  or 
mean,  value  for  the  attribute.  For  the  case  where  no  randomization  is  desired,  this  is  the 
only  value  used.  The  third  column  is  an  integer  indicating  randomization  type.  Currently, 
there  is  capability  for  gaussian  and  uniform  distributions,  as  well  as  user  defined  types. 

For  gaussian  distributions,  the  second  column  indicates  the  standard  deviation.  For 
uniform  distributions,  the  second  column  indicates  the  lower  bound  of  the  distribution.  If 
the  distribution  is  user-defined,  the  set  of  values  are  provided  in  separate  files. 

Randomization  is  accomplished  by  passing  the  input  file  data  through  a  randomization 
block,  executed  only  at  the  start  of  the  simulation.  This  is  shown  in  Fig.  8. 


Fig.  8.  Randomization  of  model  attributes 

On  the  left  side  of  Fig.  8  is  shown  a  DEMUX  block  which  takes  the  entire  set  of 
attributes  from  the  input  file  as  a  single  vector  and  pulls  off  the  set  of  3  parameters  (mean, 
std  dev,  randomization  type)  for  each  attribute.  The  example  in  Fig.  8  is  for  a  component 
with  6  attributes.  The  right  side  of  Fig.  8  shows  the  heart  of  the  randomization  block, 
where  a  single  value  is  generated  based  on  the  user  specified  randomization.  Note  that  if 
the  randomization  type  =  0,  this  means  no  randomization  is  done  and  the  "mean"  is 
returned. 


As  a  result  of  the  MSTARS  randomization  architecture,  any  attribute  of  any  model  in 
the  simulation  can  be  specified  as  a  Monte  Carlo  parameter  for  run-to-run  variation  and  for 
run  set  to  run  set  variation. 

4.6.  Use  of  DLLs 

One  very  useful  feature  of  VisSim  is  its  ability  to  import  external  programs  or 
diagrams  which  have  been  "code  generated"  into  C-code.  In  either  approach,  a  Windows 
DLL  is  created  which  can  be  imported  as  a  User  Function  block.  These  two  approaches 
are  described  below: 

Externally  Developed  User  Functions: 

User  functions  can  be  written  in  practically  any  language  for  which  a  compiler  exists 
that  can  generate  a  Windows  DLL.  Most  common  compilers  fall  into  this  category.  At 
MNGG,  we  have  created  DLLs  in  FORTRAN,  C,  C++,  and  Ada  95.  According  to  Visual 
Solutions,  Pascal  can  also  be  used. 

The  use  of  external  DLLs  allows  for: 

•  Reuse  of  legacy  code  that  would  otherwise  have  to  be  converted  to  a  diagram 

•  Creation  of  special  purpose  utilities 

•  Creation  of  models  which,  for  one  reason  or  another,  are  more  easily  developed  in  a 
language  environment. 

The  MSTARS  system  has  DLLs  representing  each  of  the  above  types.  Special  DLLs 
were  created  for  data  I/O.  Existing  FORTRAN  and  Ada  code  has  been  imported  into  the 
system.  And  new  models  have  been  developed  in  C  and  C++. 

Code  Generated  Diagrams: 

A  source  code  generator  is  available  from  Visual  Solutions  which  can  be  used  to 
selectively  generate  C-code  for  all  or  part  of  a  model  represented  in  a  VisSim  diagram. 

This  code  can  be  compiled  as  a  DLL  so  that  it  can  be  imported  into  a  diagram  in  place  of 
the  diagram-based  model  or  it  can  be  compiled  as  a  separate  executable  program.  Use  of 
DLLs  coded  from  a  diagram  based  model  serves  two  basic  purposes: 

•  It  speeds  the  model  up  significantly 

•  It  allows  creation  of  multi-rate  simulations  where  even  continuous  integrations  can 
be  done  at  different  rates  in  different  models 


4.7.  Multiple  Rate  Simulations 


As  simulations  become  more  complex,  it  becomes  very  important  to  be  able  to 
simulate  each  subsystem  at  its  own  rate,  which  may  or  may  not  be  the  same  as  the 
simulation  update  rate.  This  is  done  primarily  to  speed  up  the  simulation  and  to  model 
simulation  rates  for  an  actual  subsystem. 

There  are  three  ways  to  get  the  effect  of  multiple  subsystem  rates: 

•  For  discrete  or  hybrid  subsystems  which  have  discrete  delays  and  integrators,  these 
are  simply  simulated  using  VisSim  discrete  blocks  set  at  the  appropriate  time  step. 

•  For  subsystems  which  have  continuous  Laplace-domain  integrators  (1/S  blocks) , 
multiple  rates  can  be  achieved  using  the  code  generator  (a  separate  Visual  Solutions 
product)  on  the  subsystem.  The  coded  version  runs  at  the  rate  which  was  set  at 

the  time  code  generation  was  accomplished.  It  runs  at  this  rate  no  matter 
what  the  simulation  time  step,  if  incorporated  back  into  a  VisSim  diagram. 

•  For  the  general  situation  of  update  rates  not  requiring  integrators,  the  best  approach 
is  to  use  the  enabled  subsystem  feature  (VisSim  Beta  version  3.5)  to  accomplish 
triggering  a  block  at  the  desired  update  rate.  An  example  is  shown  below  in  Fig.  9. 
In  this  structure,  the  Attributes  block  reads  in  model 


Fig.  9.  Targeting  Filter  illustrates  triggered  block  approach 


M 


parameter  data  from  an  input  file  as  usual.  One  of  those  parameters  is  update  rate. 
A  pulse  train  trigger  (inside  Attributes  block)  is  created  and  saved  in  the  scoped 
variable  ::Update_Trigger  and  this  is  used  to  drive  the  enable  connector  (connector 
at  top  left  of  diagram)  for  the  compound  block.  Using  this  approach,  the  same 
trigger  variable  is  also  available  to  lower  level  components  inside  the  block 
diagram  which  may  have  discrete  blocks  that  need  to  run  at  the  same  rate. 

By  using  a  combination  of  these  three  techniques,  we  can  achieve  a  variety  of  multiple 
rate  configurations  needed  for  analysis. 


4.8.  Windows  Directories 

The  last  aspect  of  MSTARS  Simulation  System  architecture  which  will  be  covered 
here  is  the  use  of  the  Windows  system  itself  as  part  of  the  architecture. 

Many  modeling  systems  contain  elaborate  special  purpose  dialogs  and  tools  for 
selection  of  models  and  accomplishing  various  tasks.  These  are  very  nice,  but  require 
much  time  and  effort  to  develop.  If  the  modeling  system  changes,  the  special  purpose 
graphical  tools  must  change  as  well.  MS  Windows  has  many  built  in  features  which  can 
be  used  to  great  advantage  without  resorting  to  special  purpose  dialogs  and  requires  no 
extra  effort.  In  the  MSTARS  system,  directories  are  arranged  to  logically  organize 
components  according  to  type  and  function.  Sample  input  fdes  are  provided  in  each 
directory  containing  a  model  which  can  be  cut  and  pasted  into  a  large  input  fde  containing 
attributes  for  many  models.  Double  clicking  a  model  or  simulation  brings  up  VisSim  and 
automatically  loads  the  model.  Notepad  and  Write  are  used  extensively  in  creating  input 
files  and  data  files. 

By  making  use  of  features  already  built  into  Windows,  much  time  and  effort  was  saved 
over  building  special  purpose  interactive  dialogs. 


5.  Impact  On  Simulation  &  Analysis  Process 

Having  a  visual  environment  for  creating  models  and  conducting  analysis  has  a 
profound  impact  on  the  way  work  is  accomplished  Some  examples  in  particular: 

•  Simulation  parameters  such  as  integration  type,  time  step,  and  various  runtime 
options  can  be  set  from  a  menu,  saving  tremendous  time  over  manual  techniques 

•  The  merits  of  a  particular  model  architecture  can  be  inspected  visually  in  seconds 
instead  of  spending  much  time  sifting  through  pages  of  source  code 

•  Building  modes  hierarchically  from  a  component  library  consists  of  cutting  and 
pasting  with  a  mouse  rather  than  laboriously  writing  call  statements  in  a  source 
code  program 


•  An  intuitive  environments  results  in  more  time  for  creative  thinking  about  the  real 
engineering  issues  instead  of  worrying  about  source  code  architecture 

•  Fewer  errors  are  made  due  to  intuitively  obvious  visual  connections 

•  Very  rapid  swapping  and  testing  of  new  ideas  can  be  accomplished  compared  to  the 
source  code  environment. 

•  There  is  a  greatly  enhanced  ability  to  share  models  and  ideas  with  colleagues  who 
can  very  quickly  understand  the  big  picture.  This  is  not  possible  with  a  huge 
compiled  language  program  because  the  parts  are  scattered  over  possibly  hundreds 
of  pages  of  code 

•  Debugging  is  quicker  in  the  visual  environment  because  of  features  built  into  the 
commercial  tools,  such  as  color  coded  blocks  indicating  errors,  ability  to  instantly 
see  parameter  values  using  the  mouse,  and  easily  tracing  signal  paths  through  a 
simulation. 

To  further  compare  use  of  the  visual  environment  to  use  of  a  typical  source  language 
environment,  it  is  illuminating  to  look  at  the  typical  process  involved  in  developing  a 
model  of  a  new  munition  and  doing  comparative  trade-off  studies  for  a  new  technology 
subsystem  such  as  a  seeker.  In  the  source  language  environment,  the  process  might  work 
something  like  this: 

•  Complete  a  new  simulation  of  the  munition  or  try  to  configure  an  existing 

munition 

simulation  for  the  work  (several  weeks  to  several  months). 

•  Debug  the  munition  simulation  (several  days  to  several  weeks) 

•  Add  features  which  were  neglected  in  the  initial  design  (several  days  to  several 
weeks) 

•  Develop  a  model  of  the  new  subsystem  (several  days  to  several  weeks) 

•  Integrate  the  new  subsystem  into  the  munition  simulation  and  debug  (several  days 
to  several  weeks) 

•  Debug  the  new  simulation  (several  days  to  several  weeks) 

•  Conduct  simulations  of  munition  performance  for  new  versus  old  subsystem 
(severed  days) 

For  the  visual  environment  with  reusable  components,  the  same  process  might  look 
like  this: 

•  Use  the  component  library  to  build  a  prototype  munition  similar  to  the  desired 
munition  (several  minutes) 

•  Conduct  analysis  using  the  prototype  munition  model  to  determine  additional 
features  needed  (several  minutes  to  several  hours) 

•  Build  the  new  features  into  the  new  simulation  (several  hours  to  several  days) 

•  Debug  the  simulation  (several  minutes  to  several  hours) 

•  Use  the  component  library  to  select  a  subsystem  model  similar  to  the  new 
subsystem  (several  minutes) 

•  Conduct  analysis  using  the  simulation  to  determine  requirements  for  the  new 
subsystem  model  (several  minutes  to  several  hours) 


•  Add  features  to  the  existing  subsystem  model  to  create  the  new  one  (several  hours 
to  several  days) 

•  Integrate  the  new  subsystem  into  the  munition  simulation  and  debug  (several 
minutes  to  several  hours) 

•  Conduct  simulations  of  munition  performance  for  new  versus  old  subsystem 
(several  days). 

Note  that  there  seems  to  be  more  steps  in  the  visual  environment,  but  the  total  time  for 
a  typical  project  is  typically  measured  in  terms  of  days  and  not  months  as  compared  to  the 
source  code  environment.  The  additional  steps  come  as  a  result  of  the  capability  for  "rapid 
prototyping"  which  makes  it  possible  to  build  something  quickly  and  interate  on  the  design 
until  it  works  as  desired.  An  important  factor  in  the  effectiveness  of  the  MSTARS 
Simulation  System  is  a  reusable  libraiy  of  components.  This  is  certainly  an  advantage  in  a 
source  code  environment  as  well,  but  it  is  not  as  effective  or  fast  as  the  visual  environment 
because  it  is  less  intuitive. 

The  net  effect  of  the  MSTARS  Simulation  System  over  previous  simulation 
approaches  used  at  MNGG  is  that  it  has  drastically  improved  the  process  of  simulation  and 
analysis:  It  is  faster,  more  effective,  and  requires  fewer  resources. 


6.  Summary 

AFRL/MNGG  has  constructed  a  visual  6-DOF  munition  simulation  system  under  the 
MSTARS  project  using  the  commercial  visual  design  tool  VisSim.  The  MSTARS 
Simulation  System  has  a  library  of  reusable  components  and  enables  rapidly  building  new 
simulations  of  guided  bombs  and  missiles  in  minimal  time.  At  this  time,  there  are  about  70 
models  in  the  component  library  which  can  be  used  in  building  munition  simulations.  New 
models  are  being  added  almost  weekly  as  needed  to  perform  required  analyses. 

The  visual  environment  has  drastically  changed  the  way  in  which  conceptual  weapon 
simulation  and  analysis  is  conducted.  Much  more  time  is  spent  in  understanding  and 
solving  engineering  problems  instead  of  focusing  on  complex  simulation  software  code. 

With  all  the  advantages,  there  are  also  some  disadvantages  of  the  visual  environment: 

•  When  it  comes  to  complicated  logic,  it  is  often  easier  to  create  the  intended  effect 
in 

a  language  enironment  because  there  is  complete  flexibility  in  creating  logic 
structures.  However,  this  situation  is  changing  and  most  visual  tool  makers  are 
putting  mechanisms  for  decision  logic  in  their  tools.  Also,  the  ability  to  import 
external  programs  into  visual  environment  means  that  each  environment  can  be 
used 

in  the  areas  for  which  it  is  best  suited,  and  a  single  visual-based  simulation  can  be 
built  combining  the  external  programs  and  visual  diagrams 


•  Complex  data  structures  can  be  represented  better  in  a  high  level  language 
(especially  Ada  95  and  C++).  Usually  this  is  not  a  critical  issue  for  most  problems 
of  interest. 

•  Speed  may  be  an  issue  depending  on  the  application.  Diagrams  are  interpreted  and 
run  slower  than  a  comparable  model  developed  and  compiled  by  a  traditional 
computer  language.  However,  code  generation  of  a  diagram  can  produce  code 

which 

is  several  times  faster  and  can  approach  the  speed  of  a  traditional  compiled 

program 

We  believe  the  tradeoffs  swing  in  favor  of  the  visual  environment.  The  advantages  far 
outweigh  the  disadvantages. 

The  MSTARS  Simulation  System  is  undergoing  constant  change  as  we  at  MNGG  learn 
new  and  better  ways  of  doing  things  and  as  the  need  for  additional  models  and  new 
capability  continue  to  grow.  We  believe  the  approach  which  was  taken  a  year  ago  in 
building  this  visual  environment  was  the  right  approach  for  our  problem  domain,  and  we 
continue  to  improve  it  to  handle  more  and  more  complex  problems. 
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ABSTRACT 

Changes  in  global  civil  airspace  architecture,  commonly  called  Communications, 
Navigation,  Surveillance,  Air  Traffic  Management  (CNS  /  ATM)  will  necessitate  changes  in 
military  avionics  equipment  and  air  traffic  service  provider  procedures.  The  military  must  work 
closely  with  civil  authorities  as  these  concepts  are  developed.  For  tactical  aircraft,  the  possibility 
of  installing  unique  equipment  to  capture  this  civil  functionality  is  unacceptable  because  of 
weight,  space,  and  cost  considerations.  For  some  of  the  communications  issues,  the  same 
AN/ARC-210  radio  the  military  is  installing  for  its  digital  functionality  has  a  growth  capability 
to  handle  the  civil  8.33  kHz  channel  separation  and  civil  VHF  Data  Link  Mode  II  and  III. 
Likewise,  the  military  GPS  receivers,  EGI  and  MAGR,  will  have  a  growth  capability  to  achieve 
the  integrity  and  Required  Navigation  Performance  (RNP-4)  for  flight  in  the  National  Airspace 
System  (NAS)  and  international  controlled  airspace.  For  the  required  civil  surveillance 
functionality,  the  dual  use  solution  has  not  yet  been  identified.  The  solution  for  some  aircraft 
might  be  the  civil  use  of  Joint  Tactical  Information  Distribution  System  (JTIDS)  information  for 
air  traffic  monitoring  through  gateways.  Another  possibility  for  a  dual  use  solution  might  be  the 
installation  of  Mode  S  in  military  aircraft  for  Automatic  Dependent  Surveillance  Broadcast 
(ADS-B).  With  this  solution,  an  upgrade  to  the  AN/APX-100  could  be  the  path  to  capture  this 
new  functionality  and  at  the  same  time  explore  the  possibility  of  a  military  utility  of  broadcast 
surveillance  architecture.  Either  way,  the  dual  use  of  each  aircraft’s  1553B  data  bus  and  cockpit 
electronic  displays  will  support  both  civil  and  military  utility. 
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INTRODUCTION 


The  tremendous  growth  in  air  traffic  presents  increasing  challenges  for  air  traffic  service 
providers,  general  aviation  (GA),  military  aviation,  and  commercial  air  carriers.  Such  growth  is 
straining  airspace  and  airport  resources.  The  current  air  traffic  system  requires  significant 
upgrades  in  order  to  increase  flight  efficiency  and  system  capacity  while  continuing  to  meet 
flight  safety  standards.  The  International  Civil  Aviation  Organization  (ICAO),  Federal  Aviation 
Administration  (FAA),  and  other  civil  aviation  authorities  (CAA)  plan  to  implement  a  new  air 
traffic  architecture  to  meet  this  need.  This  new  architecture  takes  advantage  of  emerging 
technologies  in  communication  (data  links),  navigation  (direct  routing)  and  surveillance  (self- 
reporting  with  cockpit  displays  of  traffic)  to  improve  air  traffic  safety  and  efficiency.  The  goal  is 
to  transition  to  “free  flight”,  a  concept  of  flying  with  less  restrictions  and  more  cockpit 
situational  awareness.  Free  flight  will  give  operators  the  freedom  to  choose  direct  routes,  speeds, 
and  altitudes,  in  near  real-time,  thus  providing  greater  operational  efficiency  while  raising  safety 
to  the  next  plateau.  The  Future  Air  Navigation  System  (FANS)  committee  of  ICAO  led  the  way 
with  the  implementation  of  FANS  architecture  in  the  Pacific.  ICAO  refers  to  this  new 
functionality  as  Communication,  Navigation,  Surveillance,  Air  Traffic  Management 
(CNS/ATM).  The  USAF  refers  to  these  new  concepts  as  Global  Air  Traffic  Management 
(GATM). 

The  requirements  for  CNS  /  ATM  are  derived  from  draft  implementation  plans,  ICAO 
Standards  and  Recommended  Practices  (SARPS),  RTCA  Minimum  Aviation  System 
Performance  Standards  (MASPS)  and  Minimum  Operational  Performance  Standards  (MOPS), 
the  Airlines  Electronic  Engineering  Committee  (AEEC)  ARINC  Characteristics  and  Standards, 
Aeronautical  Information  Circulars  (AIC),  etc.  The  time  line  for  implementation  of  this  new 
functionality  varies  from  region  to  region  with  most  of  the  near  term  issues  focused  in  the  North 
Atlantic  air  routes  and  European  airspace.  Within  military  aviation,  transport  aircraft  will  be 
impacted  first  and  most  of  the  military  effort  to  date  has  been  focused  on  transport  type  aircraft. 

For  tactical  military  aircraft  to  operate  in  this  new  environment,  significant  modifications 
to  existing  aircraft  could  be  required.  The  civil  avionics  required  to  achieve  CNS  functionality 
could  have  a  significant  negative  impact  on  the  military  mission  of  these  aircraft.  Likewise,  the 
tight  fiscal  climate  deters  avionics  upgrades  that  do  not  make  a  positive  contribution  to  the 
aircraft’s  warfighting  mission.  There  are  few  nonmaterial  alternatives  available  for  military 
aircraft  that  fly  in  controlled  airspace.  It  is  expected  that  non-compliant  aircraft  will  receive 
handling  delays  or  non-optimal  routes  and/or  altitudes.  The  efficiency  of  the  military  aircraft’s 
passage  through  controlled  airspace  will  be  degraded  and  in  some  cases,  the  aircraft  will  be 
excluded.  Tactical  military  aircraft  will  continue  to  fly  in  restricted  areas,  warning  areas,  and 
international  open  ocean  airspace  under  the  “due  regard”  option  which  obligates  the  military 
aircraft  commander  to  be  his  own  air  traffic  control  agency  and  to  separate  his  aircraft  from  all 
other  traffic.  For  due  regard  flight  in  instrument  meteorological  conditions  (IMC),  a  military  air 


traffic  service  provider  must  provide  flight  following.  However,  if  the  aircraft  is  to  cross  into 
sovereign  controlled  airspace,  the  CNS  capability  specified  for  that  airspace  will  prevail  and 
compliance  will  be  expected. 

COMMUNICATIONS 

With  the  implementation  of  CNS/ATM  transoceanic  routes,  where  radar  following  is  not 
available  and  over  the  horizon  flight  following  is  cumbersome,  routine  pilot-to-controller  voice 
communications  will  be  augmented  by  data  link  transmissions.  Just  as  an  E-Mail  is  a  different 
form  of  communications  than  a  phone  call,  data  links  to  aircraft  will  introduce  new  functionality 
not  available  over  voice  communications.  Even  though  voice  connectivity  will  always  be 
required,  as  navigation  accuracy  increases  and  aircraft  separation  requirements  decrease,  data 
link  functionality  will  become  mandatory.  A  primaiy  objective  of  the  CNS/ATM  system  is  to 
reduce  the  traffic  separation  standards.  This  will  mandate  a  more  responsive  voice  and  data  link 
communications  capability.  The  air  traffic  service  providers  will  need  real  time  connectivity 
with  trans-oceanic  traffic  for  routing  changes,  weather  avoidance,  etc.  For  overland  and  line  of 
sight  operations,  where  radar  following  and  VHF  real  time  connectivity  is  standard,  the  limiting 
factor  for  handling  the  growth  in  air  traffic  is  the  limited  radio  frequency  (RF)  spectrum 
available.  Current  plans  to  increase  the  spectrum  capacity  are  to  utilize  reduced  channel 
separation  and  Time  Division  Multiple  Access  (TDMA)  architecture. 

COMMUNICATION  SYSTEM  COMPONENTS 

Communications  system  components  for  trans-oceanic  passenger  aircraft  include  satellite 
communications  (INMARSAT,  IRIDIUM,  etc.)  and/or  high  frequency  data  link  (HFDL)  radios 
with  state  of  the  art  communication  management  units  (CMU).  Data  link  requirements  will  be 
mandated  by  region,  with  Controller  to  Pilot  Data  Link  Communications  (CPDLC)  being  the 
ultimate  goal.  Most  tactical  aircraft  will  have  little  use  for  this  trans-oceanic  functionality. 
However,  tactical  aircraft  will  need  to  be  upgraded  to  handle  the  reduced  channel  separation 
capability,  VHF  data  link  capability,  and  VHF  TDMA  architecture. 

SPECIFIC  COMMUNICATION  REQUIREMENTS 

EUROCONTROL  intends  to  increase  spectrum  capacity  by  reducing  channel  separation 
from  25  kHz  to  8.33  kHz  frequency  spacing  as  a  near-term  fix  to  their  frequency  congestion 
problem.  This  requirement  will  be  implemented  January  1,  1999  in  the  core  of  Europe  for  the 
upper  airspace  (country  dependent:  above  FL245  in  most  countries  except  for  France,  which 
used  FL195).  It  is  planned  to  migrate  to  lower  altitudes  as  early  as  2003.  For  the  long-term 
solution  to  the  overall  VHF  frequency  congestion  problem,  both  the  US  and  Europe  endorse  the 
use  of  emerging  TDMA  technologies. 


The  near  term  civil  utility  of  VHF  data  links  will  be  to  facilitate  weather,  both  text  and 
graphical,  flight  service  information,  and  aeronautical  information  between  aircraft  and  ground 
systems.  An  office  worker  can  get  a  weather  map  via  the  Internet  for  his/her  monitor  with  a  few 
keystrokes  and  someday,  aircrews  will  be  able  to  import  graphical  weather  of  their  destination 
airfield.  Also,  Notice  to  Airman  (NOTAM)  and  Automatic  Terminal  Information  Service 
(ATIS)  will  arrive  via  data  link  upon  request.  The  ultimate  goal  of  CPDLC  will  be  implemented 
with  a  series  of  software  modifications  as  the  requirements  mature.  Just  as  modem  business  has 
found  network-centric  computing  very  useful,  tactical  military  aircraft  will  find  VHF  data  links 
very  useful  for  civil  functionality  and  network-centric  warfare. 

Military  tactical  aviation  has  a  long  history  of  UHF  communication.  Civil  air  traffic 
service  providers  installed  UHF  radios  specifically  to  provide  military  aircraft  traffic  services 
while  they  were  operating  in  controlled  airspace.  Although  this  procedure  of  talking  to  civil 
aircraft  on  VHF  and  military  aircraft  on  UHF  was  workable,  it  introduced  some  safety  issues 
since  the  VHF  users  and  the  UHF  users  operating  within  the  same  sector  could  not  hear  each 
other’s  radio  transmissions.  At  the  present  time,  military  aviation  is  transitioning  to  digital 
programmable  advanced  communications  systems  with  functionality  from  30  to  400  MHz 
frequency  range.  These  radios  are  being  installed  to  meet  the  warfighting  requirements  of 
tactical  aircraft  but  are  capable  of  capturing  the  civil  functionality  with  minor  modifications. 
The  Navy’s  AN/ARC-210  radio,  with  military  data  link  capability,  is  lightweight  and  suitable  for 
installation  in  any  military  platform.  With  over  1500  already  installed  and  plans  for  the  purchase 
of  over  3000  systems,  the  AN/ARC-210  program  manager  has  initiated  an  upgrade  effort  to 
capture  the  civil  8.33  kHz  VHF  channel  spacing  as  well  as  civil  VDL  mode  II  and  III.  With 
these  minor  modifications,  this  military  radio  will  be  interoperable  with  the  civil  air  traffic 
service  providers  throughout  the  world.  If  CPDLC  eventually  becomes  a  military  requirement, 
software  upgrades  to  the  communication  system’s  processor  will  capture  this  functionality.  This 
is  an  excellent  example  of  meeting  the  needs  of  CNS  functionality  with  minor  upgrades  to  a 
military  radio.  For  communications,  dual  use  avionics  appears  to  be  a  cost-effective  solution. 

NAVIGATION 

In  the  CNS  air  traffic  environment,  navigation  standards  will  be  defined  as  Required 
Navigation  Performance  (RNP).  Today,  civilian  navigation  equipment  is  certified  with  a 
Technical  Standard  Order  (TSO).  When  the  equipment  is  properly  installed  in  an  aircraft,  the 
aircraft  is  given  a  Supplemental  Type  Certificate  (STC).  This  certification  is  based  on  the 
demonstrated  functionality  of  the  equipment  and  the  approved  installation  within  that  aircraft. 
With  the  introduction  of  area  navigation  (RNAV),  the  aircraft’s  navigation  solution  is  probably 
the  product  of  several  sensors  and  single  box  certification  is  no  longer  appropriate.  The  entire 
navigation  system  must  be  evaluated  and  certified.  This  certification  process  brings  new 
emphasis  on  Flight  Management  Systems  (FMS)  and  the  associated  software.  The  first  aircraft 
to  be  certified  for  RNP  was  the  747-400. 
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NAVIGATION  SYSTEMS  COMPONENTS 


RNP  functionality  requires  an  aircraft  to  be  capable  of  RNAV  and  with  the  navigation 
accuracy  to  maintain  its  position  within  a  specific  number  of  Nautical  Miles  (NM)  of  its  cleared 
track.  The  aircraft  must  be  able  to  maintain  this  specified  cross  track  containment  95%  of  the 
time  for  the  duration  of  the  flight  with  an  assurance  of  99.999%  that  no  undetected  excursions 
beyond  2  x  RNP  will  occur.  This  accuracy  error  budget  includes  positioning  error,  flight 
technical  error  (FTE),  path  definition  error,  and  display  error.  Differing  levels  of  RNP  accuracy 
will  be  specified  for  different  airspace  and  regions,  and  will  be  implemented  under  different 
timelines.  Trans-oceanic  air  routes  in  the  Pacific  have  already  been  designated  for  RNP  10  and 
all  trans-oceanic  routes  are  scheduled  to  be  designated  for  RNP  4  by  2003.  Continental  Europe 
introduced  Basic  Area  Navigation  (BRNAV)  on  April  23,  1998.  BRNAV  is  equivalent  to  RNP 
of  5  NM.  They  chose  RNP  5  to  ensure  that  Global  Positioning  System  (GPS)  receivers  would 
not  be  required.  During  1998,  EUROCONTROL  will  decide  whether  or  not  to  progress  to 
Precision  Area  Navigation  (PRNAV)  which  is  equivalent  to  RNP  of  1  NM  for  some  specified 
airspace  and  terminal  areas  after  2005. 

System  performance  standards  for  RNP  are  divided  into  two  categories:  technical 
performance  requirements  and  functional  capability  requirements.  The  technical  performance 
requirements  dictate  the  accuracy,  containment  integrity,  and  containment  continuity 
(availability)  performance  of  the  navigation  system.  The  functional  capability  requirements 
define  the  features  the  navigation  system,  as  a  whole,  must  possess  in  order  to  fly  in  RNP 
airspace.  These  functional  capability  requirements  include,  but  are  not  limited  to,  a  FMS, 
displays,  interfaces,  controls,  steering  and  procedural  functions,  and  alerting.  All  system 
technical  performance  requirements  and  functional  capability  requirements  must  be  met  for  the 
aircraft  to  operate  in  RNP-4,  or  less,  airspace. 

SPECIFIC  NAVIGATION  REQUIREMENTS 

In  order  to  operate  in  a  RNP-4  or  less  airspace,  aircraft  will  require  an  integrated  GPS 
receiver  and  RNAV  functionality.  These  aircraft  also  must  be  capable  of  electronic  data  transfer 
and  have  available  a  certified  digital  database  of  flight  information.  Civil  Standard  Positioning 
Service  (SPS)  GPS  users  have  spent  years  trying  to  remove  the  impact  of  the  Selective 
Availability  (SA)  errors  intentionally  introduced  by  the  militaiy  GPS  control  segment.  To  ensure 
the  introduced  SPS  position  and  time  errors  do  not  impact  safety  of  flight;  civil  authorities  have 
mandated  tight  standards  of  SPS  GPS  accuracy,  continuity,  availability  and  integrity.  The  Wide 
Area  Augmentation  System  (WAAS),  funded  by  the  FAA,  is  specifically  designed  to  increase 
the  quality  of  SPS  GPS  for  use  in  civil  aviation.  Local  Area  Augmentation  System  (LAAS)  is 
another  way  to  remove  the  SA  errors  with  differential  GPS. 

Tactical  Military  aircraft  use  Precise  Positioning  Service  (PPS)  GPS  and  are  not  effected 
by  SA  since  these  aircraft  use  keyed  enciyption  devices  to  remove  the  errors.  Also,  the  two 
frequency  P(Y)  code  signal  used  by  the  military  is  much  more  robust  than  the  single  frequency 


C/A  signal  presently  used  by  civil  users.  Although  significant  work  is  yet  to  be  done,  the  GPS 
modernization  program  plans  to  demonstrate  unaugmented  PPS  GPS  with  sufficient  accuracy, 
availability,  continuity,  and  integrity  for  world  wide  non  precision  approach  and  Category  I 
approaches  and  landings.  Tactical  militaiy  aircraft  equipped  with  Inertial  Navigation  Systems 
(INS)  coupled  with  PPS  GPS  should  have  little  problem  meeting  the  requirements  of  RNP  4. 

The  1994  Defense  Authorization  Act  directed  the  installation  of  tactical  GPS  receivers  in 
all  military  platforms  by  September  30,  2000.  However,  the  GPS  user  equipment  installed  in 
most  tactical  aircraft  today  does  not  meet  the  integrity  standards  for  RNP  4  certification. 
Likewise,  the  presidential  decision  to  turn  off  SA  by  2006  has  forced  the  military  to  find  a  new 
way  to  ensure  a  military  utility  of  GPS  information.  This  new  effort  is  called  GPS 
Modernization  /  Navigation  Warfare  (NAVWAR)  and  will  probably  require  an  upgrade  to 
today’s  5-channel  GPS  receivers.  Tactical  military  aircraft  will  be  able  to  capture  RNP  4 
functionality  and  dual  use  utility  with  the  integrated  installation  of  the  upgraded  GPS 
Modernization  receivers.  The  upgraded  Embedded  GPS  INS  (EGI)  and  the  Miniature  Airborne 
GPS  Receiver  (MAGR  2000)  should  both  contain  all-in-view  receivers  and  meet  RNP-4  integrity 
standards.  The  certified  digital  flight  information  database  is  in  work  and  prototype  integrations 
are  planned  to  demonstrate  both  non-precision  approaches  (NPA)  and  Category  I  precision 
approaches.  This  will  be  another  example  of  achieving  CNS  functionality  with  minor  upgrades 
to  militaiy  equipment.  For  Navigation,  dual  use  avionics  is  again  the  most  cost-effective 
solution. 


SUVEILLANCE 

Air  traffic  surveillance  today  is  based  on  primary  radar  and  L-Band  (1030  &  1090  MHz) 
Secondary  Surveillance  Radar  (SSR)  collecting  information  to  build  traffic  displays  inside 
control  centers.  The  SSR  used  by  GA  is  called  Air  Traffic  Control  Radar  Beacon  System 
(ATCRBS)  with  Modes  A  and  C.  The  SSR  used  by  the  military  is  called  Identification  Friend  or 
Foe  (IFF)  with  Modes  1,2, 3, 4,  &  C.  Civil  Mode  A  is  the  same  as  military  Mode  3  and  it  is 
usually  called  Mode  3/A.  Commercial  air  carriers  have  installed  Mode  S,  which  allows  selective 
interrogation  using  each  aircraft’s  unique  Mode  S  identification.  Mode  S  is  really  a  56  bit 
airborne  digital  data  link  that  facilitates  air  to  ground  communications  and  aircraft  to  aircraft 
crosstalk.  Mode  S  transponders  also  broadcast,  or  sguitter ,  their  unique  ID  once  per  second.  All 
SSR  interrogations  are  transmitted  on  1030  MHz  and  all  aircraft  responses  or  reports  are 
transmitted  on  1090  MHz. 

The  second  main  feature  of  surveillance  is  called  Airborne  Collision  Avoidance  System 
(ACAS).  ACAS,  which  is  called  TCAS  (Traffic  Alert  and  Collision  Avoidance  System)  in  the 
FAA,  uses  the  Mode  S  squitter  and  SSR  responses  on  1090  MHz  to  track  the  identity  of  aircraft 
within  line  of  sight.  The  ACAS  box  then  interrogates  each  contact  and  establishes  the  range  and 
altitude  of  all  other  aircraft  in  the  vicinity.  When  predetermined  altitude,  range,  and  time 
conditions  are  met,  the  ACAS  produces  an  audio  traffic  alert  (TA)  for  the  pilot.  ACAS  can  also 
produce  a  vertical  resolution  advisory  (RA)  to  direct  a  vertical  aircraft  maneuver  and  ensure 


altitude  separation  at  the  closest  point  of  approach.  Additionally,  ACAS  also  has  the  ability  to 
format  the  RA  within  a  Mode  S  message  and  transmit  it  to  the  conflicting  aircraft.  The  range 
and  altitude  of  the  conflicting  aircraft  is  very  accurate,  but  the  relative  bearing  is  not  accurate 
enough  to  allow  resolution  advisories  in  the  horizontal  (come  left,  come  right).  All  ACAS 
resolution  advisories  are  in  the  vertical. 

SURVEILLANCE  SYSTEMS  COMPONENTS 

The  new  CNS  environment  will  rely  more  heavily  on  aircraft  avionics  than  does  the 
current  air  system  to  insure  safe  aircraft  separation.  Because  GPS  equipped  aircraft  can  compute 
their  own  position  more  accurately  than  air  traffic  control  radar;  aircraft  self-reports  will  soon 
become  standard.  For  trans-oceanic  routes,  where  flight  following  radar  is  not  available,  aircraft 
will  send  position  reports  addressed  to  specific  air  traffic  control  centers.  These  self-reports  will 
utilize  HFDL  or  SATCOM  data  links  and  will  be  called  Automatic  Dependent  Surveillance 
Addressed  (ADS-A).  Even  when  primary  radar  following  is  available,  aircraft  will  still 
broadcast  periodic  GPS  based  self-reports  to  allow  other  aircraft  in  the  vicinity  and  ground 
controllers  to  gain  situational  awareness.  This  use  of  broadcast  architecture  for  aircraft  self- 
reports  is  called  Automatic  Dependent  Surveillance  Broadcast  (ADS-B).  With  ADS-B,  all 
aircraft  will  be  able  to  have  Cockpit  Display  of  Traffic  Information  (CDTI)  functionality.  CDTI 
is  the  key  element  needed  to  develop  the  required  cockpit  situational  awareness  for  free  flight. 

A  recently  approved  upgrade  to  the  Mode  S  transponder  expands  the  data  link  message  to 
112  bits  and  the  new  Mode  S  extended squitter  broadcasts  the  aircraft’s  ID,  latitude,  longitude, 
altitude,  and  velocity  vector  once  per  second.  With  this  recent  expansion  of  the  Mode  S 
message,  a  new  collision  avoidance  upgrade  called  ACAS  II  or  TCAS  II  change  7,  has  been 
introduced.  This  new  functionality  captures  the  information  within  the  Mode  S  extended  squitter 
(ID,  Latitude,  Longitude,  Altitude,  and  velocity  vector)  to  build  a  geodetic  traffic  display  in  the 
cockpit.  This  CDTI  greatly  increases  situational  awareness.  The  pilot  should  have  sufficient 
situational  awareness  to  execute  traffic  deconfliction  maneuvers  in  the  horizontal  and  minimize 
the  number  of  TAs  and  RAs  produced  by  ACAS  II. 

The  Mode  S  extended  squitter  format  is  also  a  possible  solution  for  ADS-B  functionality 
in  GA  aircraft  that  don’t  have  ACAS  II  installed.  Without  installing  the  expensive  ACAS  II 
avionics  equipment  with  its  two  antennas  and  the  1030  MHz  interrogator,  GA  is  investigating  the 
functionality  of  installing  a  1090  MHz  receiver  in  the  Mode  S  transponder.  With  this  one  box 
ADS-B  solution,  GA  could  listen  to  the  extended  squitters  of  the  aircraft  around  them  and  build  a 
CDTI  in  their  cockpit.  The  participation  of  GA  in  the  Mode  S  and  ADS-B  broadcast  architecture 
could  greatly  increase  situational  awareness  and  aviation  safety.  This  effort  is  strongly  supported 
by  civil  aviation  authorities. 


SPECIFIC  SURVEILLANCE  REQUIREMENTS 


To  date,  neither  GA  aircraft  nor  tactical  military  aircraft  have  installed  either  Mode  S  or 
ACAS  avionics  equipment.  The  transition  to  CNS  surveillance  architecture  will  have  a  big 
impact  on  both  GA  and  the  military  aviation.  EUROCONTROL  has  announced  the 
implementation  dates  for  Mode  S  and  ACAS  II  and  they  present  a  significant  problem  for  GA 
and  near  term  military  operations.  ACAS  II  will  be  required  for  all  transport  aircraft  with  more 
than  30  seats  or  weight  more  than  15,000  Kg  by  January  1,  2000.  This  ACAS  II  requirement 
will  be  expanded  to  transport  aircraft  with  more  than  19  seats  and  weight  of  more  than  5,700  Kg 
by  January  1,  2005.  The  extended  squitter  Mode  S  requirement  is  extended  to  all  aircraft  filling 
IFR  flight  plans  after  January  1,  2003  and  all  VFR  flight  plans  by  January  1,  2005.  These  future 
requirements  have  been  known  for  some  time  but  little  has  been  accomplished  to  address  the 
solution  for  either  GA  or  tactical  military  aircraft. 

The  entire  topic  of  military  air  surveillance  will  require  a  significant  analysis  of  not  only 
the  requirements  to  meet  CNS  functionality  but  also  the  impact  of  ACAS  II  and  Mode  S 
equipped  aircraft  on  battlespace  management.  The  big  military  surveillance  debate  is  about  to 
begin.  One  solution  to  the  military  tactical  aircraft  CNS  functionality  issue  would  be  to  upgrade 
the  AN/APX-100  IFF  transponder  with  Mode  S  and  ADS-B  functionality.  This  solution  would 
mirror  the  GA  plan  to  capture  ADS-B  without  installing  ACAS  II.  This  option  deserves  a  lot  of 
thought  and  this  minor  upgrade  to  the  AN/APX-100  could  also  make  it  possible  to  address 
known  deficiencies  in  Mode  4  and  also  investigate  the  utility  of  an  encrypted  version  of  ADS-B 
to  enhance  military  utility.  For  the  CNS  Surveillance  issue,  a  dual  use  option  is  available  but 
considerable  work  will  be  required  to  bring  it  to  the  front. 

CONCLUSION 

The  1998  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  Master  Positioning,  Navigation, 
and  Timing  Plan  (CJCSI  6 130.01  A)  states  military  aircraft  must  be  equipped  with  suitable 
instruments  and  navigation  equipment  appropriate  to  the  routes  to  be  flown.  Navy  and  Marine 
Corps  tactical  aircraft  are  not  required  to  install  avionics  equipment  that  meets  FAA  Technical 
Standard  Orders  (TSO)  or  ICAO  Standards  and  Recommended  Practices  (SARPS).  However, 
the  minimum  performance  standards  for  military  aircraft,  to  be  developed  by  the  respective 
Services,  must:  conform  with  civil  airspace  required  navigation  performance  (RNP)  standards. 
prevent  violation  of  civil  air  traffic  clearances,  ensure  safe  separation  of  military  and  civil  air 
traffic,  and  ensure  military  aircraft  achieve  an  “Equivalent  Level  of  Safety”.  Each  aircraft’s 
requirements  will  depend  on  its  mission  but  within  the  next  few  years,  most  tactical  military 
aircraft  will  require  some  communications,  navigation,  and  surveillance  (CNS)  avionics 
upgrades  to  ensure  access  to  sovereign  controlled  airspace.  The  specific  avionics  changes  for 
each  aircraft  are  still  unknown  but  those  under  consideration  include: 

•  PPS  GPS  with  integrity  for  primary  means  of  navigation 

•  Area  Navigation  (RNAV)  functionality 

•  Required  Navigation  Performance  (RNP-4) 

•  8.33  kHz  VHF  channel  spacing 

•  VHF  digital  data  link  functionality 


•  Mode  S 

•  Collision  Avoidance  functionality 

If  the  U.  S.  Military  tactical  aircraft  fail  to  install  the  appropriate  avionics  functionality,  loss  of 
access  to  specific  sovereign  controlled  airspace  should  be  anticipated.  The  road  map  to  an 
affordable  solution  to  these  issues  probably  lies  in  dual  use  functionality  of  military  avionics. 
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ACRONYMS 


ACAS 

Airborne  Collision  Avoidance  System 

ADS-A 

Automatic  Dependent  Surveillance  Addressed 

ADS-B 

Automatic  Dependent  Surveillance  Broadcast 

AEEC 

Airlines  Electronic  Engineering  Committee 

AIC 

Aeronautical  Information  Circulars 

ARINC 

Aeronautical  Radio  Inc. 

ATCRBS 

Air  Traffic  Control  Radar  Beacon  System 

ATIS 

Automatic  Terminal  Information  Service 

BRNAV 

Basic  Area  Navigation 

CAA 

Civil  Aviation  Authorities 

CDTI 

Cockpit  Display  of  Traffic  Information 

CJCS 

Chairman  of  the  Joint  Chiefs  of  Staff 

CMU 

Communication  Management  Units 

CNS/ATM 

Communications,  Navigation,  Surveillance,  Air  Traffic  Management 

CPDLC 

Controller  to  Pilot  Data  Link  Communications 

EGI 

Embedded  GPS  INS 

FAA 

Federal  Aviation  Administration 

FANS 

Future  Air  Navigation  System 

FMS 

Flight  Management  Systems 

FTE 

Flight  Technical  Error 

GA 

General  Aviation 

GATM 

Global  Air  Traffic  Management 

GPS 

Global  Positioning  System 

HFDL 

High  Frequency  Data  Link 

ICAO 

International  Civil  Aviation  Organization 

ID 

Identification 

IFF 

Identification  Friend  or  Foe 

IMC 

Instrument  Meteorological  Conditions 

INS 

Inertial  Navigation  Systems 

JTIDS 

Joint  Tactical  Information  Distribution  System 

LAAS 

Local  Area  Augmentation  System 

MAGR  2000 

Miniature  Airborne  GPS  Receiver 

MASPS 

Minimum  Aviation  System  Performance  Standards 

MOPS 

Minimum  Operational  Performance  Standards 

NAS 

National  Airspace  System 

NAVWAR 

Navigation  Warfare 

NM 

Nautical  Miles 

NOTAM 

Notice  to  Airman 

NPA 

Non-Precision  Approach 

PPS 

Precise  Positioning  Service 

PRNAV 

Precision  Area  Navigation 

RA 

Resolution  Advisory 

RF 

Radio  Frequency 

RNAV 

Area  Navigation 

RNP 

Required  Navigation  Performance 

RTCA 

RTCA  Inc. 

SA 

Selective  Availability 

SARPS 

Standards  and  Recommended  Practices 

SATCOM 

Satellite  Communications 

SPS 

Standard  Positioning  Service 

SSR 

Secondary  Surveillance  Radar 

STC 

Supplemental  Type  Certificate 

TA 

Traffic  Alert 

TCAS 

Traffic  Alert  and  Collision  Avoidance  Syste 

TDMA 

Time  Division  Multiple  Access 

TSO 

Technical  Standard  Order 

UHF 

Ultra  High  Frequency 

VFR 

Visual  Flight  Rules 

VHF 

Very  High  Frequency 

WAAS 

Wide  Area  Augmentation  System 
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1.0  SUMMARY 

The  most  significant  consolidation  in  the  U.S.  Department  of  Defense  (DoD)  just  occurred  at  the 
Naval  Air  Station  in  Patuxent  River,  Maryland.  This  air  station  is  commonly  referred  to  as  "Pax 
River."  The  U.S.  Navy  collocated  its  aircraft  program  managers,  developers,  testers,  procurement,  and 
logistics  personnel  at  Pax  River  to  achieve  greater  efficiency  and  effectiveness  in  buying  aircraft 
weapon  systems.  The  purpose  of  this  paper  is  to  discuss  this  consolidation  and  the  tremendous 
research,  development,  test  and  evaluation  (RDT&E)  capability  now  resident  at  this  site. 

2.0  BACKGROUND 

Challenge 

With  the  end  of  the  Cold  War  and  the  subsequent  dissolution  of  the  Soviet  Union,  the  priority  and 
funding  of  national  defense  declined  over  the  past  decade.  The  challenge  to  the  US  Navy  in  the  early 
1990's  was  to  substantially  downsize  the  work  force,  reduce  the  number  of  support  sites,  and  retain 
sufficient  capability  to  support  the  Fleet  in  anticipation  of  this  new  reality. 

-Approach 

In  1989,  the  total  number  of  Navy  civilians  across  the  U.S.  associated  with  the  acquisition  and  support 
of  naval  aviation  systems  totaled  52,000  people.  The  Navy's  end  strengths  goal  for  1999  is  28,000. 
This  represents  a  46  percent  reduction  in  work  force.  In  1989,  the  total  number  of  shore  station  sites 
was  18  including  headquarters  and  field  activities.  The  Navy's  goal  for  1999  is  to  have  8  sites  in 
operation.  This  represents  a  55  percent  reduction  in  shore  station  sites. 

In  addition  to  the  downsizing  and  consolidating  more  functions  at  fewer  sites,  the  Navy  also 
reorganized  its  entire  Naval  Aviation  acquisition  corps  around  a  new  organizational  structure  and 
concept  of  operations  to  improve  the  efficiency  of  the  acquisition  process. 

Consolidation  at  Pax  River 


Since  1943,  the  Pax  River  complex  has  served  as  the  Navy's  principal  aircraft  test  and  evaluation 
facility.  From  1945  until  1992,  the  complex  was  known  as  the  home  of  the  Naval  Air  Test  Center. 

Due  to  actions  taken  as  a  result  of  a  nationwide  Base  Realignment  and 

3.0  PAX  RIVER  RDT&E  CAPABILITY 

The  NAWCAD  Pax  River  organization  represents  an  enormous  consolidation  of  engineering  talent, 
facilities,  and  aircraft  at  one  site.  The  NAWCAD  work  force  is  currently  1 1 ,400  employees  composed 
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of  1,300  military,  4,100  civil  service,  and  6,000  contractor  personnel.  A  total  of  67  scientific  and 
engineering  laboratories  are  at  Pax  River  as  a  result  of  this  consolidation.  There  are  also  137  RDT&E 
aircraft  to  support  the  acquisition  mission. 

Research  and  Development  Capability 


North  Engineering  Center 

As  part  of  the  BRAC  process,  Pax  River  received  new  facilities  to  accommodate  the  influx  of  the  new 
technical  staff  and  laboratories.  The  North  Engineering  Center,  a  new  255,000  square  foot  (23,690  sq 
m)  facility,  was  built  principally  to  accommodate  the  ASW  research  and  development  engineers  who 
moved  from  Wanninster,  Pennsylvania  The  center  is  approximately  65%  laboratory  space  and 
accommodates  over  400  personnel.  The  facility  houses  hardware  integration  centers  and  software 
production  facilities  for  maritime  surveillance  aircraft.  Within  the  North  Engineering  Center  is  a  large 
acoustic  sensors  laboratory  which  is  used  for  the  development  of  new  ASW  sensors. 

The  North  Engineering  Center  is  located  adjacent  to  the  Force  Aircraft  Test  Squadron  (FATS)  which 
conducts  technical  testing  of  air  ASW  weapon  systems.  The  aircraft  are  used  by  both 
research  and  development  and  test  and  evaluation  personnel.  In  addition,  the  operational  test  and 
evaluation  squadron,  VX- 1,  is  located  next  to  FATS  which  allows  for  the  timely  transition  of 
technology  from  the  research  and  development  laboratory  to  the  operational  test  and  evaluation 
community  due  to  this  collocation. 

South  Engineering  Center 

The  South  Engineering  Center,  a  new  450,000  square  foot  (41,807  sq  m)  facility,  was  built  principally 
to  accommodate  the  influx  of  air  vehicle,  aircrew  systems,  and  avionics  technologists  from 
Warminster,  Pennsylvania  and  NAVAIR  headquarters.  The  facility  houses  over  800  engineers  and 
scientists. 

Within  the  South  Engineering  Center  are  numerous  air  vehicle,  aircrew  systems,  and  avionics  labs. 
One  of  these  is  the  Horizontal  Accelerator,  a  certified  facility  used  for  operational  testing  and 
evaluation  of  various  systems  in  crash  environments.  The  heart  of  the  facility  is  an  accelerator  capable 
of  providing  controllable  and  repeatable  time-mirrored  crash  pulses  simulating  the  conditions  which 
occur  during  crash  on  land  or  in  water.  The  facility  has  supported  tests  and  evaluation  of  rigid  and 
energy-attenuating  seats,  ejection  seats,  clothing  assemblies,  restraints,  and  body-mounted  equipment. 

Materials  Laboratory 

The  Robert  N.  Becker  Laboratory  is  adjacent  to  the  South  Engineering  Center.  This  laboratory  is 
home  to  the  aerospace  materials  division  at  Pax 
_78,000  square-foot  (7,246  sq  m)  building. 

Test  and  Evaluation  C3nabilities 


Air  Station 

The  Pax  River  Complex  is  located  60  miles  (97  km)  south  of  Washington,  D.C.,  and  90  air  miles  (145 
km)  from  the  Fleet  in  Norfolk,  Virginia  (Figure  5).  The  complex  is  composed  of  a  7,000  acre  (28.3  sq 
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km)  Naval  Air  Station  at  Patuxent  River,  Maryland,  and  an  850  acre  (3.4  sq  km)  Webster  Field  annex 
located  10  miles  (16  km)  away.  The  main  all-weather  sea  level  airfield  at  Pax  River  has  three  heavy 
capacity  runways: 

6,400  ft;  9,700  ft;  and  11,800  ft  (1,951  m,  2,957  m,  and  3,597  m)  long.  Eleven  hangars  provide  over 
1 .2  million  square  feet  of  space  (111  ,483  sq  m). 

AirSpace 

The  Pax  River  Complex  is  located  beneath  a  restricted  air  space  controlled  by  Naval  Air  Station  Air 
Operations.  The  restricted  air  space  is  approximately  60  miles  (96  km)  by  30  miles  (48  km)  wide. 

This  restricted  air  space  and  the  Warning  Areas  immediately  off  the  East  Coast  provide  50,000  square 
miles  (129,500  sq  km)  of  air  space  in  which  to  conduct  flight  test  operations. 

Naval  Test  Wing  Atlantic 

Currently,  Pax  River  is  the  busiest  flight  test  center  in  the  world  with  over  20,000  hours  being  flown 
by  the  Naval  Test  Wing  Atlantic,  an  organizational  arm  of  the  Test  and  Evaluation  Group(Figure 
3).  Flight  operations  include  activities  performed  by  the  Strike,  Rotary  Wing, 
and  Force  aircraft  test  squadrons  and  the  U.S.  Naval  Test  Pilot  School.  Strike  platforms  include  the 
F/A-i  8,  F-i  4,  EA6B,  T-  45,  and  UAV's;  surveillance  aircraft  such  as  the  E-2C,  P-3,  and  S-3;  and 
rotary  wing  aircraft  such  as  the  V-22,  SH-6013,  UH-60,  and  CH-53  helicopters. 

Test  Article  Preparation 

The  Test  Article  Preparation  group  provides  aircraft  irurumentation  and  aircraft  modification  services. 
A  complete  metal  shop  and  composite  shop  capability  allow  rapid  prototyping  of  aircraft 
modifications  which  enables  proof-of-concept  testing  aboard  RDT&E  aircraft.  Recent  activities  have 
included  the  integration  of  missiles  aboard  maritime  patrol  aircraft  and  the  incorporation  of  guns 
aboard  Navy  helicopters. 

Atlantic  Ranges  and  Facilities 

The  Atlantic  Ranges  and  Facilities  Department  provides  both  flight  and  ground  test  facilities 
necessary  for  the  comprehensive  evaluation  of  aircraft  weapon  systems.  Significant  ground  and  flight 
test  facilities  include  the  following: 

Air  Combat  En~ironment  Test  and  Evaluation  Facility  (ACETEF):  This  facility  is  a  fully 
integrated  ground  test  facility  allowing  full-spectrum  test  and  evaluation  of  aircraft  and  aircraft 
systems  in  a  secure  and  controlled  engineering  environment.  The  facility  uses  state-of-the-art 
simulation  and  stimulation  techniques  to  provide  test  scenarios  that  will  reproduce  actual  combat 
conditions.  Aircraft  systems  are 

Aircraft  Test  and  Evaluation  Facility  (ATEF):  The  ATEF  provides  the  capability  to  ground  test 
installed  aircraft  propulsion,  mechanical,  electrical,  and  pneumatic  subsystems  in  a  controlled 
environment,  during  static  and  engine  operating  conditions.  This  facility  is  an  enclosed,  acoustically 
designed  building  which  can  operate  24  hours  per  day  regardless  of  noise  or  weather  restrictions.  The 
facility  can  be  made  "light  tight"  and  provides  a  suitable  environment  for  the  evaluation  of  night 
vision  devices. 


Dynamic  In-Flight  Radar  Cross  Section  Measurements 


The  Radar  Cross  Section  ~CS)  measurement  facility  conducts  dynamic  in-flight  RCS,  jammer-to- 
signal  ratio,  chaff  measurements  relative  to  aircraft,  helicopters,  UAV's,  towed  targets,  and  decoys. 
The  integrated  facilities  provide  telemetry,  tracking  data,  range  control,  airborne  instrumentation,  and 
RCS  data  acquisition,  all  in  a  centralized  workstation  allowing  analysis  and  display  of  the  in-flight 
dynamic  RCS  measurements  in  real  time.  Data  products  include  RCS  amplitude  versus  aspect, 
Doppler  power  spectrum,  downrange  profiles,  and  Inverse  Synthetic  Aperture  Radar  imagery 
measurements. 

Electronic  Warfare  Flight  Test  Facility  ~WFTF) 

The  EWFTFis  comprised  of  a  wide  variety  of  highly  sophisticated  equipment  that  supports  the  test 
and  evaluation  community.  These  discrete  systems  (made  up  of  transmitters,  receivers,  tracking  and 
slaved  antenna  pedestals,  fixed  antennas,  emitter  control  circuitry,  and  computers)  are  configured  to 
generate  a  wide  variety  of  radar  and  communication  radio  frequency  signatures  in  support  of  aircraft 
electronic  warfare  (EW)  avionics  test  measurements.  The  EW  facility  also  develops,  maintains,  and 
operates  special  purpose  data  acquisition,  processing  and  display  systems.  The  combination  of  these 
systems  and  the  RF  signature  generators  is  used  to  support  a  wide  variety  of  in-flight  EW  integration 
test  measurements. 

Automatic  Carrier  Landing  Systems  (ACLS)  Facility 

The  ACLS  Facility  has  cradle-to-grave  responsibility  for  air  traffic  control  and  landing  systems  used 
onboard  carriers,  amphibious  assault  ships,  and  Marine  Corps  expeditionary  airfields.  This  facility 
provides  the  ability  to  correlate  airborne  data,  ground  systems  data,  and  independent  tracking  data  for 
flight  analysis.  The  facility  assures  that  these  landings  systems  provide  safe  and  reliable  approach  and 
landing  guidance  to  all  shipboard  and  expeditionary  aircraft  in  all  weather  and  sea  state  conditions. 
The  facility  supports  the  development  and  testing  of  current  and  future  systems,  new  and  modified 
hardware  and  software,  and  the  development  of  both  ground  and  airborne  control  systems. 

Carrier  Suitability  Facilities 

Carrier  suitability  facilities  include  a  steam  catapult  and  arrestment  engine  on  one  of  the  runways.  Use 
of  these  facilities  is  necessary  to  determine  if  new  or  modified  equipment  installed  on 
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Abstract 

This  paper  presents  a  concept  for  laboratory  utilization  and  networking  in  support  of 
avionics  systems  development  and  integration  for  Naval  Aviation.  The  Naval  development 
centers  for  air  systems  have  a  number  of  separate  laboratory  facilities  that  deal  with  the 
many  facets  of  avionics  systems  in  Navy  airborne  platforms.  The  laboratories  associated 
in  developing  and  implementing  this  concept  are  those  located  at  the  Naval  Air  Warfare 
Centers  (NAWCs)  at  Patuxent  River  MD,  China  Lake  CA  and  Point  Mugu  CA.  The 
purpose  of  exploring  and  then  implementing  this  concept  is  to  ensure  that  the  Navy  makes 
maximum  use  of  the  laboratory  resources  available,  and  through  networking,  provides  a 
capability  for  multiple  center  participation  in  shared  program  developments. 

The  effort  underway  is  embodied  in  two  elements:  Modular  Avionics  Integration 
Laboratory  (MAIL)  and  Modular  Avionics  Integration  Network  (MAIN).  The  MAIL 
element  is  concerned  with  the  identification  and  networking  together,  laboratory  resources 
within  the  confines  of  a  single  development  center.  The  MAIN  concept  is  a  networking 
approach  for  linking  the  three  centers  so  that  inter-center  participation  can  be  achieved  for 
broad  scope  systems  development  and  integration  programs.  Taken  together,  the  MAIN 
and  MAE.  represent  a  forward  step  towards  implementing  a  consistent  systems 
engineering  based  process  for  avionics  systems  evaluation,  development  and  integration 
for  the  Navy. 


1 .0  Introduction 

In  the  current  era  of  downsizing,  the  tendency  is  to  examine  every  resource  for  its  value  to 
the  enterprise.  Resources  of  the  Naval  Air  Systems  Command  (NAVAIR)  “Naval 
Aviation  Systems  Team”  are  continually  being  assessed  and  evaluated  to  determine 
whether  value  added  (often  measured  as  return  on  investment)  merits  their  retention.  Over 


the  years,  the  Navy  has  acquired  numerous  laboratory  elements  widely  dispersed 
throughout  the  many  facilities  that  support  the  NAVAIR  Team.  Generally,  each  of  these 
separate  laboratory  elements  has  a  special,  often  unique,  function  that  is  important  to  Naval 
aviation.  Taken  together  these  laboratory  elements  comprise  an  important  national  resource. 
MAIN/MAIL  is  a  concept  for  enhancing  and  ensuring  full  utilization  of  the  existing 
laboratory  facilities  throughout  the  Naval  Aviation  Systems  Team  community. 

Modular  Avionics  Integration  Laboratory  (MAIL)  describes  a  laboratory  utilization 
approach  focused  on  resources  contained  within  a  single  Navy  development  center. 
Typically  any  networking  done  to  support  MAIL  is  accomplished  by  and  within  the  range 
of  a  local  area  network  (LAN).  The  Modular  Avionics  Integration  Network  (MAIN) 
extends  the  overall  functionality  of  the  MAIL  concept  by  adding  a  networking  capability  to 
link  Navy  development  centers  that  are  hundreds  or  thousands  of  miles  apart.  The 
MAIN/MAIL  concepts,  taken  together,  create  a  broad  basis  for  more  effective  utilization  of 
existing  laboratory  resources  on  a  full  enterprise  basis. 


2.0  MAIN/MAIL  Structure  and  Organization 

The  original  organization  structure  for  MAIN/MAIL  consists  of  the  NAWC  Aircraft 
Division  and  NAWC  Weapons  Division  development  centers  under  NAVAIR,  Avionics 
Department  leadership.  It  is  expected  that  as  the  concept  is  implemented  and  further 
evolves  that  other  facilities  (such  as  the  Depots)  will  be  integrated  into  the  system.  The 
fundamental  organization  is  shown  in  Figure  1 . 
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Figure  1.  The  fundamental  organization  of  MAIN/MAIL 

Figure  1  presents  an  organization  that  utilizes  the  fundamental  functional  work  break  down 
structure  (WBS)  that  exists  in  the  resources  of  the  Naval  Air  Systems  Command  in 
establishing  MAIN/MAIL.  As  shown,  at  a  top  level,  China  Lake  is  primarily  responsible 
for  weapons  technology,  weapons  development  and  weapons  integration.  Patuxent  River  is 
primarily  responsible  for  avionics  technology  and  avionics  systems  concepts  development. 


Point  Mugu  has  primary  responsibility  for  electronics  warfare  and  information  systems 
technology  and  EW/IS  systems  development.  This  is  a  topdown,  work  breakdown,  and 
generally  true  although  elements  of  some  of  the  major  functional  areas  exist  at  other  than 
the  principal  development  center.  The  starting  point  for  the  MAIL  at  each  of  the 
development  centers  is  to  provide  a  laboratory  system  to  support  the  development  of  key 
supporting  technologies  and  their  transition  to  operational  systems.  The  laboratory  is 
configured  to  support  system  development  and  developmental  testing  and  evaluation. 
Each  MAIL  is  intended  to  primarily  support  the  functional/  technology  area  as  defined 
locally  at  each  of  the  participating  development  centers.  The  areas  of  technology 
specialization  are  shown  in  Table  1.  The  Avionics  Department  S&T  Program  ( AIR-4. 5T 
directed)  Maritime  Aviation  Subsystems  and  Technology  (MAST)  Program  has  an 
identified  focus  for  avionics  technology  and  architecture  research  and  is  primarily 
administered  and  performed  at  Patuxent  River  MD.  Each  of  the  other  Centers  receive 
funding  in  the  technology  areas  identified. 


Naw  Center 

Technoloqv  Area 

China  Lake,  CA 

Weapons,  Weapons  Integ. 

Patuxent  River,  MD 

Avionics,  Core  Processing 

Point  Mugu,  CA 

Electr.  Warfare,  Info  Sys. 

Table  1.  Technology  Emphasis  Areas  at  Navy  Air  Warfare  Centers 


The  first  purpose  of  each  MAIL  is  to  provide  a  facility  to  demonstrate  and  exercise 
products  from  Navy  S&T  initiatives  in  the  technology  areas  assigned.  It  is  expected  that 
this  utilization  will  help  to  make  S&T  developments  more  meaningful  and  facilitate 
effective  technology  transition.  Additionally  the  MAILs  serve  as  entry  points  for 
demonstrations  of  prototype  technologies  and  systems  (often  proprietary)  to  the  Navy.  The 
MAILs  also  can  serve  as  development  testbeds  for  Cooperative  Research  And 
Development  Agreements  (CRADAs)  and  other  joint  development  efforts  with  Industry, 
NASA,  DARPA  and  the  other  military  services  in  an  attempt  to  broaden  the  business  base 
for  more  effective  utilization  of  Navy  laboratories. 


2.1  Networking  between  Centers:  MAIN 

The  MAIN  concept  unifies  the  laboratory  resources  of  the  three  Development  Centers  by 
providing  effective  networking  between  the  individual  MAILs.  MAIN  provides  additional 
fidelity  by  making  all  resources:  simulations,  laboratory  tools,  etc.  available  for  large 
system  demonstrations  and  feasibility  experiments.  MAIN  will  utilize  the  network 
capability  of  the  Defense  Research  Engineering  Network  (DREN),  Naval  Aviation  Wide 
Area  Network  (NAYWAN)  and  other  telecommunications  links  as  needed.  Although  the 
distance  between  centers  adds  data  latency  issues,  pseudo-realtime  experiments  can  be 
conducted  to  evaluate  basic  feasibility  for  many  systems  problems.  Figure  2  Illustrates  the 
basic  networking  configuration  envisioned. 


Figure  2.  MAIN  Networking  between  Navy  Centers  for  Effective  Laboratory 

Integration/Resource  Sharing 


Figure  2  presents  a  basic  interconnection  diagram.  As  the  network  evolves  and  the 
business  basis  expands,  additional  linkage  to  Navy  Depots,  Joint  Service  and  Industrial 
sites  is  likely.  The  “network  centric  approach  to  warfare  now  being  pursued  is  equally  valid 
for  the  exploration,  development  process  for  weapon  systems  [1].  As  conceived,  each  of 
the  Centers  would  establish  a  “centerwide”  MAIL  to  link  local  laboratory  facilities  as 
appropriate  to  satisfy  technological  and  architectural  needs  within  its  areas  of  expertise. 
This  local  networking  will  utilize  existing  resources  to  the  maximum  extent  possible, 
adding  new  facilities  only  as  a  last  resort  if  needed  to  achieve  overall  capability. 


2.2  MAIL/MAIL  Leadership 

AIR-4.5  has  taken  the  leadership  role  for  development  of  the  MAIN/MAIL  initiative.  As 
the  Avionics  Department,  AIR-4.5  is  responsible  for  providing  the  engineering  support  to 
program  offices  responsible  for  the  development  and  full  life  cycle  support  of  avionics 
systems.  This  responsibility  includes  setting  the  policies  for  Navy  avionics  systems  and 
assuring  that  the  engineering  disciplines  required  for  the  avionics  “competency”  are 
properly  trained  and  available  to  the  avionics  program  offices.  The  actual  development  and 


acquisition  activities  are  the  responsibilities  of  the  program  offices  that  develop  avionics 
systems  and  the  platform  program  offices  that  utilize  these  avionics  in  aircraft  and  airborne 
platforms.  However,  these  program  offices  of  necessity  must  focus  on  a  specific 
development.  Overall  avionics  policy,  avionics  systems  engineering  procedures  and 
processes,  consistent  avionics  architectures  and  commonality/affordability  approaches  on  a 
macro  level  are  the  responsibility  of  the  avionics  competency,  AIR-4.5.  To  accomplish  its 
mission,  AIR-4.5  has  initiated  the  MAIN/MAIL  Program  as  a  first  step  towards  full 
integration  of  its  laboratories  into  an  effective  National  asset  for  avionics  leadership  for  the 
Navy.  Coupled  with  the  laboratory  network  integration  plan  is  an  expanded  business 
concept  that  embraces  shared  development  activity  with  the  Tri-Services,  DARPA,  NASA 
and  Industry  (both  commercial  and  military). 

Air-4.5  leadership  believes  that  network  based  laboratory  integration  similar  to  that 
proposed  will  naturally  occur  over  time  on  an  ad  hoc  basis.  MAIN/MAIL  is  a  program  to 
accelerate  this  process  and  assure  that  network  integration  is  properly  planned  and 
effectively  implemented. 


2.3  The  MAIN/MAIL  Enterprise  Team 

A  MAIN/MAIL  Team  has  been  formed  to  provide  direct  “hands-on”  management  of  the 
concept  development  and  implementation  process.  The  Enterprise  Team  lead  is  William 
H.  Schibler  of  AIR-4.5T.  Other  principal  members  are  from  each  of  the  participating  Navy 
Centers.  Additionally,  numerous  others  from  involved  focus  laboratories,  experts  on 
networking  and  other  technologies  important  to  MAIN/MAIL  are  included  on  the  Team.  A 
considerable  amount  of  work  has  taken  place.  Team  meetings  have  been  held  at  each  of  the 
participating  NAWCS  and  through  frequent  Video  Tele-Conference  (VTC)  status  reviews. 
Many  of  the  meetings  have  been  held  in  parallel  with  laboratory  tours  to  provide  a  more  in- 
depth  understanding  of  the  many  individual  laboratory  resources.  Initial  work  of  the 
Enterprise  Team  centered  around  the  identification  and  classification  of  the  many 
laboratory  elements.  A  database  describing  each  of  the  individual  laboratories  has  been 
assembled  as  a  starting  point  for  implementation. 


3.0  The  Need 

The  underlying  requirement  for  MAIN/MAIL  is  to  provide  a  multi-functional  avionics 
development  and  integration  laboratory  across  the  NAVAIR  Avionics  Department,  AIR- 
4.5.  The  Avionics  Department  “competency”.  The  MAIL  provides  an  enhancement  of  the 
“core”laboratory  capability  in  support  of  Navy  Air  program  offices  and  Joint  Service 
program  offices.  The  flexibility  and  reconfigurability  offered  by  MAIN/M  AIL  networking 
will  complement  the  capabilities  of  existing  laboratory  resources  and  provide  a  “value 
added”  to  their  utilization.  The  functional  requirements  for  a  laboratory  system  are 
somewhat  volatile,  changing  in  response  to  new,  emerging,  technologies  and  system 
architectural  trends.  Recent  trends  in  systems  engineering  have  emphasized  the  use  of  rapid 
prototyping  techniques  to  synthesize  and  evaluate  systems  concepts  more  quickly  and 
affordably.  These  trends  and  emphasis  areas  place  great  value  on  the  versatility  and 
reconfigurability  that  inter-laboratory  networking  provides. 

At  a  top  level,  the  mission  for  MAIN/MAIL  can  be  summarized  by  the  following  key 
elements: 
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•  Provide  a  framework  to  demonstrate  and  transition  new  technologies  into  current 

programs 

•  Provide  a  facility  to  support  joint  service  programs,  cooperative  research  and 
development  projects  with  Industry,  and  shared  initiatives  with  NASA,  DARPA 
and  others 

•  Support  programs  to  develop  advanced  avionics  architectures  and  systems 
concepts  through  Enterprise  level  S&T  initiatives  and  investigations 

•  Serve  as  a  resource  to  exercise  and  evaluate  open  systems  standards  and 
commercial  off-the-shelf  (COTS)  products  as  candidates  for  Naval  avionics 

systems  and  architectures 

•  Provides  a  “hands-on”  capability  for  training  of  scientific  and  engineering 
personnel  of  the  Avionics  Department. 

•  Linking  of  the  laboratory  resources  of  the  NAWCs  and  other  NAVAIR  facilities 
provides  a  structure  for  moving  toward  a  common  systems  engineering  process 
across  the  entire  enterprise 


Each  of  these  key  elements  is  discussed  below: 

3.1  A  Framework  to  Transition  S&T  Products 

Navy  S&T  programs  are  often  criticized  for  failure  to  effectively  transition  S&T  research 
into  advanced  development  programs  leading  to  in-service  operational  systems. 
Technology  transition  is  difficult  at  best  for  a  number  of  reasons.  Workload  and  scheduling 
problems  pose  a  major  barrier  to  effective  technology  transfer.  Program  Offices  find  it 
difficult  to  make  key  personnel  available  to  travel  far  and  wide  to  attend  S&T  technology 
reviews.  Further,  it  is  often  difficult  to  assess  the  risk  involved  with  a  new  technology 
without  significant  additional  evaluation.  As  a  result,  potentially  useful  technologies  are 
often  omitted  because  credible  risk  versus  benefits  assessments  are  not  available.  On  the 
other  side  of  the  equation,  those  engaged  in  Navy  S&T  planning  and  administration  have 
little  budget  or  time  available  to  engage  in  full  scale  marketing  to  and  coordination  with  the 
potential  user  PMA  community.  As  a  result,  much  of  the  S&T  activity  is  out  of  phase  with 
program  office  needs  in  both  content  and  timing.  Recently  there  have  been  several  efforts 
to  provide  better  coordination  between  the  S&T  community  and  Naval  Aviation  Program 
Offices.  Notable  among  these  are  the  efforts  of  the  Strike  Vision  Design  Team  (SVDT), 
established  jointly  by  the  Office  of  Naval  Research  (ONR)  and  the  Naval  Aviation  Science 
&  Technology  Office  (NAVSTO).  Through  joint  efforts  of  members  of  the  SVDT  and  the 
F/A-18  Program  Office  a  process  designated  as  the  Advanced  Technology  Review  Board 
(ATRB)  process  has  been  developed  to  identify  and  prioritize  high  payoff  S&T  programs 
[2],  [3].  These  efforts  have  been  pointed  towards  a  more  effective,  high  payoff  Naval 
research  S&T  program,  coordinated  with  and  integrated  into  the  applicable  PMA  program 
roadmaps.  The  ATRB  goal  was  to  improve  the  ability  of  the  Program  Manager  to 
implement  emerging  technologies  in  his  platform.  The  ATRB  process  was  originally 
developed  by  the  SVDT  in  coordination  with  the  F/A-18  Core  Avionics  Integrated  Product 
Team  (IPT).  The  process  was  first  utilized  by  the  F/A-18  PMA  in  1997.  A  feature  of  the 
work  done  was  that  S&T  products  and  continuing  parallel  S&T  development  efforts  have 
been  incorporated  into  the  “outyears”  of  the  F/A-18  roadmap,  far  beyond  that  done 
previously.  To  establish  a  much  higher  probability  of  effective  technology  transfer,  the 
ATRB  process  has  been  extended  to  other  programs  and  is  currently  being  utilized  for 


S&T  transition  planning  for  PMA-201,  Conventional  Weapons  [4];  and  PMA-209,  Air 
Combat  Electronics.  Information  gathered  using  this  process  will  be  used  as  a  basis  for 
technology  planning  for  the  ONR/AIR-4.5T  Maritime  Aviation  Sub-Systems  & 
Technology  (MAST)  Program. 

In  addition  to  the  improved  efforts  to  coordinate  S&T  efforts  with  the  needs  of  the  PMAs, 
another  problem  encountered  is  that  of  achieving  suitable  exposure  of  advanced 
technologies  and  systems  concepts  to  the  appropriate  PM  A  decision  makers.  It  is  expected 
that  MAIN/MAIL  can  help  to  solve  this  problem.  By  providing  laboratory  facilities  to 
demonstrate  and  showcase  new  technologies  over  an  extended  period  of  time,  effective 
exposure  to  potential  “customer”  PMAs  is  much  more  likely  to  occur.  Further,  the 
MAIN/MAIL  system  can  be  used  to  perform  the  risk  assessment  versus  benefits 
comparisons  needed  to  justify  the  use  of  the  subject  technologies  and/or  systems.  Long 
term  usage  of  the  MAIN/MAEL  to  host  the  products  of  S&T  research,  can  so  permeate  the 
transition  process  that  future  S&T  projects  can  be  tailored  to  provide  products  to 
demonstrate  in  the  laboratory.  An  extension  of  this  concept  can  be  used  to  assure  that  the 
products  of  S&T  research  are  architecturally  compatible  and  complementary  to  previous 
and  parallel  efforts.  Consistent  use  of  MAIN/MAIL  can  result  in  increased  focus  of  S&T 
efforts  so  that  the  tendency  is  to  create  architectural  structures  that  blend  the  key  emerging 
technologies  into  effective  systems. 

3.2  A  facility  for  an  Expanded  Business  Base 

Initial  business  planning  for  MAIN/MAIL  has  identified  a  number  of  potential  customers 
for  an  expanded  business  base.  Initially,  it  is  expected  that  the  business  utilization  for  the 
laboratory  resources  from  traditional  customers  will  increase  due  to  the  added  capability, 
architectural  flexibility  and  increased  fidelity  provided  by  the  networking  provided. 
Additional  business  areas  include  the  following: 

•  Integration/Development  laboratory  for  PMAs;  Emphasize  commodity  PMAs 
that  do  not  currently  have  a  core  laboratory  facility 

•  Increase  in  Programs  that  are  shared  between  NAWC,  Aircraft  Division  and 
NAWC,  Weapons  Division  through  use  of  the  MAIN  networking  capability 

•  Provide  a  facility/capability  to  support  key  Navy  IRAD  programs 

•  Expanded  participation  in  Multi-Service  Joint  programs 

•  Coordinated  Programs  with  other  Government  Agencies;  promote  expanded 
efforts  with  NASA,  the  Defense  Advanced  Research  Projects  Agency  (DARPA), 
FAA,  et  al 

•  Increased  joint  govemment/industry  developments.  Expand  programs 
conducted  under  Cooperative  Research  and  Development  Agreements  (CRADA), 
and  Small  Business  Innovative  Research  (SBIR)  initiatives. 


3.3  Enterprise  S&T  initiatives 

The  MAIN/MAIL  laboratory  resource  provides  a  base  for  hosting  Naval  Air  Enterprise 
S&T  initiatives.  Such  initiatives  become  important  when  the  Navy  needs  to  evaluate  a 
promising  systems  concept,  but  isn’t  certain  of  its  overall  value  and  hasn’t  any 
experimental  basis  on  which  to  fully  define  the  system  requirements.  In  such  instances  the 
Navy  isn't  prepared  to  contract  for  an  industrial  development  and  needs  an  arena  for 
experimentation  and  evaluation.  Typically  such  enterprise  projects  involve  a  number  of 
disparate  technologies  and  system  techniques,  require  multi-disciplinary  skills  and  are 
larger  in  scope  than  the  typical  in-house  S&T  project.  MAIN/MAIL  can  be  utilized  to  host 
such  focused  enterprise  programs  and  allow  Navy  engineers  and  scientists  to  determine  the 
value  and  ultimately  the  requirements  for  such  systems.  One  illustrative  example  might  be 
to  try  out  in  combination  a  number  of  experimental  Situation  Awareness  (SA)  enhancing 
techniques  that  haven’t  been  experimentally  evaluated  against  Naval  crewstation  needs.  The 
scope  of  the  project  could  involve  measurement  of  workload  and  situation  awareness  for 
different  combinations  of  enhancement  techniques,  measured  against  Navy  specific  flight 
scenarios.  A  project  of  this  scope  could  utilize  rapid  prototyping  tools,  pilot-in-the-loop 
(PITL)  simulation  and  advanced  processors  and  display  generation  equipment.  The  multi¬ 
disciplinary  nature  of  the  task  would  require  a  widely  diverse  Integrated  Product  Team 
(IPT)  which  would  include  human  factors  specialists,  experienced  pilots  to  participate  in 
the  evaluations,  display  and  processor  engineers  and  system  development/rapid 
prototyping  specialists.  The  product  evaluations  and  any  subsequent  requirements 
generated  can  be  explicitly  tailored  to  Navy  needs.  The  experience  gained  in  projects  of  this 
type  can  provide  valuable  experience  to  the  Navy  practitioners  involved  and  contribute  to  a 
more  experienced,  professional  approach  to  any  subsequent  contractual  development  for 
integration  into  an  operational  platform. 

3.4  Support  for  Standardization  Activities 

MAIN/MAIL  provides  a  capability  to  support  Naval  aviation  participation  in  avionics  and 
electronics  systems  standardization  initiatives.  It  is  important  if  Open  Systems  Standards 
are  to  be  effectively  utilized  that  Navy  personnel  participate  in  standards  development 
organizations  and  assure  that  the  needs  of  Navy  avionics  systems  are  incorporated  as 
standards  are  prepared,  reviewed  and  revised.  Key  commercial  standards  organizations 
such  as  the  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  and  the  Avionics 
Systems  Division  (ASD)  of  the  SAE  are  particularly  appropriate.  Figure  3  diagrams  the 
standardization  process  that  is  appropriate  for  the  needs  of  military  avionics  systems. 
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Figure  3.  The  Standardization  Process  and  the  role  of  MAIN/MAIL  in 
Supporting  a  Navy  role  in  Avionics  standardization 


As  shown  in  Figure  3,  standardization  is  achieved  by  selecting  and  supporting  a  system 
compatible  set  of  avionics  systems  standards.  The  selection  process,  extracts  systems 
interface  standards  from  current  avionics  and  includes  them  in  a  set  of  preferred  standards. 
Figure  3  illustrates  the  process  currently  being  employed  by  the  SAE  Avionics  Systems 
Division  in  support  of  the  DoD  Open  Systems  Joint  Task  Force  (OSJTF).  ASD  has  been 
chartered  to  create  a  catalog  of  standards  to  populate  the  OSJTF  Avionics  Standards 
Domain.  As  shown  in  the  figure,  the  standards  are  continually  being  updated  as  new 
requirements  for  avionics  systems  are  defined  and  as  new  technologies  are  introduced.  As 
shown  in  the  Figure,  it  is  expected  that  the  Avionics  Department,  AIR-4.5  would 
participate  in  the  review  of  standards  and  participate  in  the  committees  that  develop  and 
revise  existing  standards.  MAIN/MAIL  is  viewed  as  a  major  supporting  tool  for  this 
process,  by  providing  the  training  that  qualifies  Navy  representatives  to  participate  in  the 
standardization  process.  MAIN/MAIL  also  provides  a  test  bed  for  evaluating  Open 
Systems  and/or  COTS  standards. 


3.5  Training  basis  for  utilization  of  MAIN/MAIL 

Under  AIR-4.5  leadership,  the  MAIN/MAIL  can  be  utilized  for  “hands-on”  training  with 
avionics  systems.  Coordination  among  the  three  centers  can  assure  that  a  cadre  of  in-house 
experts  in  all  of  the  elements  of  avionics/airbome  electronics  will  have  laboratory  facilities 
to  maintain  their  expertise.  Availability  of  MAIN/MAIL  will  support  the  effective  transfer 
of  expertise  from  senior  technical  personnel  to  new  replacement  personnel. 

Future  technical  training  can  emphasize  a  “hands-on”  knowledge  of  emerging  technology 
by  demonstrating  new  technologies  directly  in  the  laboratories.  It  is  expected  that  “lessons 
learned  experiences”  gained  through  utilizing  the  MAIN/MAIL  will  be  accumulated  and 
provided  as  lessons  learned  for  future  training  of  avionics  engineers  and  scientists. 


3.6  Support  of  a  Common  Systems  Engineering  Process 

MAIN/MAIL  provides  a  framework  for  the  development  and  implementation  of  a 
common  systems  engineering  process  throughout  the  Naval  Air  Systems  Command 
laboratories.  The  integration  process  to  prepare  the  laboratories  to  communicate  and  work 
together  under  MAIN  networking,  requires  some  focusing  on  standard  interfaces,  standard 
tools  for  requirements  definition  and  analysis,  and  standardization  of  development 
processes.  AIR-4.5  shares  responsibility  for  avionics  processes,  and  architecture  definition 
with  the  Program  Offices  as  part  of  its  Avionics  Competency  responsibilities.  A  goal  of 
AIR-4.5  is  to  achieve  a  greater  degree  of  unity  throughout  the  Avionics  Competency.  Joint 
participation  of  both  NAWC,  Aircraft  Division  and  NAWC,  Weapons  Division  in  the 
development  and  implementation  of  a  common  systems  engineering  process  will  be  a  step 
forward  in  achieving  greater  national  unity. 

Systems  Engineering  Process  Standardization 

AIR-4.5  has  prepared  a  set  of  reference  guides/handbooks  for  systems  engineering, 
computer  resources,  and  other  key  avionics  elements.  It  is  proposed  to  use  the  existing 
handbooks  as  a  starting  point  and  enhance  with  specific  documentation  utilized  at  each  of 
the  centers.  MAIN/MAIL  provides  an  opportunity  to  unify  the  three  centers  through  shared 
consideration  and  documentation  of  standard  systems  and  software  engineering  process. 

Standard  Tools 

A  compendium  of  standard  computer  based  systems  and  software-engineering  tools  will 
be  pursued.  Default  standards,  tools  that  are  identified  with  certain  elements  and  phases  of 
the  systems  engineering  processes  will  be  identified  and  considered  for  adoption 
throughout  the  MAIN/MAIL  laboratory  elements.  The  goal  is  to  unify  the  separate  centers 
and  systems  engineers  through  common  tools  and  common  understanding  of  the  tool 
utilization. 


4.0  MAIN/MAIL  Functions 

The  basic  functionality  of  the  MAIN/MAIL  system  is  to  provide  a  technology/systems 
demonstration  facility  with  a  rapid  prototyping  capability.  The  laboratory  system  is  utilized 
for  proof-of-concept  and  risk  reduction  studies  and  evaluations.  Through  its  networking 
capability,  the  laboratory  provides  a  great  deal  of  flexibility  and  reconfigurability.  Using 
networking,  laboratory  elements  can  be  selectively  chosen  to  create  a  laboratory  architecture 


that  is  consistent  with  the  architecture  of  the  system  or  system  concept  under  development 
and/or  evaluation.  The  complement  of  tools  and  resources  necessary  to  satisfy  the 
functional  requirements  of  MAIN/MAIL  include  the  following: 

•  “Hot  Bench”  capability  to  host  prototype  systems 

•  Architecturally  broad,  Proof  of  Concept  test  bed,  Achieved  by  networking  of 
various  simulation,  stimulation,  and  hardware  in  the  loop  resources 

•  Provide  a  Software/Systems  Engineering  Environment  to  support  system 

development  and  integration. 

•  Necessary  instrumentation  and  software  based  tools  to  support  diagnostics  and 
systems  engineering  functions 

5.0  Definition  and  Implementation  of  MAIN/MAIL 

Under  direction  of  the  MAIN/MAIL  Enterprise  Team,  planning  and  early  implementation 
has  begun.  Progress  on  definition  and  implementation  of  the  MAIN/MAIL  concept 
consists  of  a  number  of  elements  as  described  below. 

5.1  MAIL  Networking,  Aircraft  Division 

Initial  work  at  Patuxent  River  has  identified  the  following  candidate  laboratories  for  a  first 
phase  linking  under  the  MAIL  concept: 


•  Mission  Computers  &  Processors  Lab 

•  IR  Systems  Evaluation  Facility 

•  Surveillance  Radar  Lab 

•  Information  Fusion  Lab 

•  EO  Sensors  Lab 

•  IR  Engineering  Lab 

•  Crew  Technology  Lab,  Mission 
Control  Ready  Room 


•  Advanced  Software  Technologies  Lab 

•  Image  &  Signal  Processing  Lab 

•  Crew  Technology  Lab,  Sim.  Facility 

•  SAR  Processing  Lab 

•  IR  Project  Spaces 

•  Tactical  Radar  Exploitation  Lab 

•  Air  Combat  Environment  T&E  Facility 
(ACETEF) 


Table  2.  Initial  List  of  Resources  for  the  Patuxent  Aircraft  Division  MAIL  Network 


The  laboratories  listed  in  Table  2  are  the  initial  candidates  for  MAIL  networking  at  Patuxent 
River.  These  laboratories  were  selected  because  they  are  key  in  exploring  advanced 
technology  and  system  architecture  development.  The  broad  diversity  of  this  set  of 
laboratories  suggests  the  many  architectural  variations  that  are  possible  as  the  laboratories 
are  selectively  interconnected  on  a  project  by  project  basis.  The  same  sort  of  diversity  exists 
at  China  Lake  and  Point  Mugu  as  well  adding  numerous  other  technologies  and  system 
emphasis  areas.  At  Patuxent  River,  a  number  of  initial  demonstration  projects  have  been 
planned,  utilizing  a  number  of  the  laboratory  resources  identified  in  Table  2.  Additionally, 
discussions  are  underway  to  link  the  facilities  at  St.  Inigoes,  MD  to  the  Patuxent  River 
laboratory  and  simulation  resources  and  ultimately  through  MAIN/MAIL  networking,  to 
other  laboratory  and  simulation  resources  at  China  Lake  and  Point  Mugu. 


5.2  Air  Interoperability  Center 

At  NAWC,  Aircraft  Division,  Patuxent  River,  MD,  the  Air  Interoperability  Center  (AIC) 
Project  provides  an  infrastructure  resource  for  linking  together  many  key  S&T  laboratories 
and  test  facilities  to  better  leverage  their  collective  capabilities.  The  hub  of  this  network  is 
the  Air  Combat  Environment  T&E  Facility  (ACETEF),  a  tri-service  DoD  funded  Installed 
Systems  Test  Facility  that  serves  as  the  focal  point  for  ongoing  programs  such  as  Joint 
Strike  Fighter  and  Joint  Theater  Missile  Defense.  The  AIC  project  consists  of  two  key 
phases: 

Phase  1.  An  ongoing  MILCON-based  task  to  install  miles  of  high-capacity  “blown”  fiber 
optic  cabling  around  the  Patuxent  River  complex.  The  entire  cable  plant  is  certified  as  a 
“Protected  Distribution  System”  (PDS)  to  allow  the  routing  of  classified  scientific  & 
engineering  data  between  key  facilities  and  buildings  without  the  use  of  cryptographic 
equipment. 

Phase  2.  An  extensive  application  development  task  to  provide  AIC  application  support 
for  ongoing  and  new  programs,  leveraging  the  new  PDS  fiber  optic  system  infrastructure. 
Efforts  of  the  MAIN/MAIL  team  are  being  coordinated  with  the  AIC  project  team  in  order 
to  make  maximum  usage  of  AIC  networking.  Figure  4  provides  a  conceptual  view  of  the 
AIC  backbone  network  and  its  utilization  to  interconnect  the  laboratory  resources  of  MAIL 
with  other  resources  at  Patuxent  River.  Figure  4  also  indicates  the  external  networking 
interfaces  of  AIC,  which  will  be  utilized  by  MAIN  for  interconnection  outside  the  Patuxent 
River  complex. 


MFS  -  Manned  Flight  Simulator 
ATM  -  Asynchronous  Transfer  Mode 
Broadband  Switching 


NAWCAD  ATM  BACKBONE 
NETWORK 

(Air  Interoperability  Center) 


Figure  4.  A  Conceptual  View  of  AIC  Network  Utilization 


The  AIC  backbone  network  utilizes  Asynchronous  Transfer  Mode  (ATM)  broadband 
switching.  ATM  is  flexibly  adaptable  to  many  protocols  using  both  real-time  and  non  real¬ 
time  engineering  applications  with  LAN  emulation  and  independent  network  control. 


5.3  MAIL/MAIN  Networking,  Weapons  Division 

A  number  of  resources  at  the  NAWC  Weapons  Division  (WD)  have  been  identified  for 
inclusion  under  MAIN/MAIL.  These  resources,  both  at  China  Lake,  CA  and  Point  Mugu, 
CA  are  listed  in  Table  3. 


•  Virtual  Prototype  Facility 

•  Missile  SIMLAB  ( IR,  RF,  HWIL) 

•  F/A-18  Sensors  Lab 

•  Range  Control 

•  Electronic  Combat  Range 


•  Inertial  Development  Lab 

•  F/A-18  Weapons  Syst.  Support  Facility 

•  F-14  Weapons  Syst.  Integ.  SIMLAB 

•  Missile  Simulation  Evaluation  Lab 

•  Data  Link  Lab 


Table  3.  Initial  List  of  Resources  for  the  Weapons  Division  (China  Lake  and  Point  Mugu) 

MAIL/MAIN  Network 


Many  of  the  resources  listed  in  Table  3  have  been  linked  previously  to  satisfy  program 
needs.  T1  lines  have  been  used  to  link  resources  between  China  Lake  and  Point  Mugu  in  a 
number  of  joint  simulation  projects. 


5.4  Demonstration  Projects 

A  number  of  demonstration  projects  are  planned  to  initiate  MAIN/MAIL  utilization.  These 
projects  will  provide  additional  experience  in  linking  multiple  laboratory  elements.  The 
experience  gained  from  these  projects  will  be  used  to  develop  value  added/retum  on 
investment  projections  for  MAIN/MAIL.  The  following  demonstrations  are  planned  for 
1998  and  will  be  performed  at  the  NAWC,  Aircraft  Division  at  Patuxent  River,  MD  to 
demonstrate  the  viability  of  the  concept.  Each  of  the  demonstrations  requires  additional 
networking  between  laboratories  that  will  be  provided  as  part  of  the  MAIN/MAIL  project. 


Demonstration  1.  Demonstrate  Direct  Coupling  of  Sensor  Fusion  Output 
Signals  to  Crew  Systems  Applications 

This  demonstration  links  the  Information/Sensor  Fusion  laboratory  with  the  Mission 
Computers  &  Processors  Laboratory  and  with  the  Crewsystems  laboratory.  This 
demonstration  will  utilize  COTS  (Open  System)  processors  to  apply  sensor  fusion 
algorithms  to  sensor  output  signals  and  provide  this  information  directly  to  the 
crewsystems  simulators.  This  will  allow  validation  of  the  sensor  fusion  algorithms  and  the 
ability  of  the  COTS  processors  to  handle  the  data.  This  demonstration  will  also  provide  a 


more  realistic  crewstation  simulation  to  resolve  pilot  workload  and  situation  awareness 
issues 


Demonstration  2.  SAR  Processing  Directly  Coupled  to  Crew  Systems 
Display  Lab 

The  Synthetic  Aperture  Radar  (SAR)  Laboratory  has  the  capability  of  providing  recorded 
“real-time”  data  to  users  as  required.  The  data  can  be  raw  radar  data  as  well  as  processed 
data.  Utilization  of  a  high-speed  network  connection  will  allow  the  data  to  be  displayed 
remotely  over  the  MAIN/MAIL  networks.  Networked  to  a  series  of  using  laboratories, 
SAR  data  can  be  utilized  as  part  of  a  testbed  for  RDT&E  to  exercise  technologies  such  as 
processors,  displays  and  data  fusion  techniques.  Distributed  SAR  data  can  also  be  applied 
to  such  applications  as  mission  planning,  battlespace  awareness,  intelligence,  surveillance 
and  reconnaissance. 

Demonstration  3.  EO/IR  Lab  Coupled  to  Crewsystems  Display  Lab 

This  demonstration  will  add  networking  between  the  EO/IR  laboratory  and  the 
Crewsystems  Display  laboratory.  This  interconnection  will  enable  the  testing  and 
evaluation  of  multi-spectral  data  display  (combining  of  multi-spectral  data  on  a  single 
display)  and  sensor  fusion  by  the  combining  of  EO/IR  and  /or  radar  and/or  LADAR  data. 
This  demonstration  will  also  provide  for  the  testing  and  demonstration  of  COTS  hardware 
and  operating  systems  to  meet  the  needs  of  sensor  specific  signal  processing  algorithms  on 
real  sensor  data. 

Demonstration  4.  Tactical  Radar  Lab  Demonstration  conducted  with 
Industry 

This  demonstration  will  be  performed  under  a  CRADA  with  Northrop-Grumman 
Baltimore.  Under  the  CRADA,  Northrop-Grumman  will  provide  an  AN/APG-66  (F-16) 
radar  system  to  the  Tactical  Radar  laboratory  at  Patuxent  River.  The  Tactical  Radar 
laboratory  will  then  be  linked  to  a  number  of  laboratories  that  can  utilize  tactical  radar  data. 
This  laboratory  was  never  intended  to  be  networked,  so  the  addition  of  external  networking 
will  add  significantly  to  its  utility.  Additionally,  the  laboratory  possesses  some  unique 
Non-Cooperative  Target  Identification  (NCTI)  processors  that  will  interface  to  the 
AN/APG-66  radar.  Under  the  terms  of  the  CRADA,  the  radar  will  be  available  for  R&D 
and/or  the  Test  and  Evaluation  of  new  hardware  and  software  components 


6.0  Architecture  Concepts  and  Issues 

In  1993,  the  Naval  Air  Systems  Command  published  a  study  of  advanced  avionics 
architecture  and  technology  trends  [5],  [6].  One  of  the  key  findings  of  this  study  was  that 
because  of  the  diversity  of  Naval  aircraft  missions,  a  single  architecture  won’t  satisfy  all 
applications.  Although,  a  single  architecture  won’t  suffice,  it  is  important  that  the  Navy 
agree  on  a  minimum  number  of  standard  architectures  in  order  to  achieve  the  economy  of 
scale  necessary  to  realize  affordable  avionics.  As  a  result,  system  architecture  is  an 
important  avionics  concern.  Some  architectural  standardization  is  required  to  effectively 
utilize  integrated/highly  modular  avionics.  The  following  sections  address  a  number  of 
important  architecture  issues,  many  of  which  are  closely  coupled  to  the  effective  utilization 
of  MAIN/MAIL. 


6.1  Standard  Architecture  Concepts 

In  order  to  achieve  the  economies  of  scale  offered  by  standardization,  it  is  important  that 
standard  architectural  approaches  be  adopted  where  justified.  Although  no  single 
architecture  can  satisfy  all  applications,  if  a  standard  development  process  is  adopted, 
common  tools  are  utilized  and  a  core  set  of  standard  interfaces  can  be  agreed  upon, 
systems  developed  will  exhibit  an  architectural  consistency  that  will  promote  more 
affordable  systems.  It  is  the  purpose  to  establish  common  architectures  for  avionics, 
weapons  control  and  integration,  electronic  warfare  suites  and  information  systems. 
Through  MAIN/MAIL  development  and  utilization  it  is  proposed  to  establish  these 
common  architectures  and  look  for  as  much  commonality  as  possible  among  the  specific 
sub-architectures.  The  goal  is  to  achieve  an  overall  architecture  of  airborne  electronic 
systems  that  serves  to  integrate  avionics,  flight  controls  and  displays,  EW/IS  systems  into 
a  consistent  architecture  to  emphasize  commonality  and  minimize  integration  engineering 
issues. 

The  common  architecture  framework  provides  consistency  in  transitioning  S&T  products 
and  provides  a  basis  for  more  affordable  common  avionics  systems.  This  architectural 
standardization  must  be  coordinated  with  standardization  activities  of  SAE,  INCOSE  and 
others,  achieving  standardization  jointly  with  military  and  industry  representation.  A 
standard  architectural  platform  will  provide  a  reference  for  evaluation  the  suitability  of 
COTS  standards  and  COTS  products. 


6.2  Avionics  Architecture  Trends 

For  the  last  twenty-five  years  or  so,  military  avionics  systems  have  been  characterized  by 
use  of  federated  systems  architectures.  In  these  systems,  avionics  functions  have  been 
packaged  as  discrete  subsystems,  often  in  separate  enclosures  or  “black  boxes”.  System 
integration  has  been  accomplished  primarily  by  busing  together  the  separate  sub-systems 
to  create  a  complete  avionics  suite  of  equipments.  The  principal  integration  tool  has  been 
the  standard  aircraft  multiplex  data  bus,  in  its  current  version  MIL-Std-1553B.  This  bus 
provides  the  basic  integration  function  through  a  “command-response”  protocol. 
Employing,  a  twisted-shielded  pair  transmission  system,  MIL-Std-1553  has  provided 
effective  system  integration  beginning  with  the  F-16  and  continuing  to  current  aircraft  such 
as  F-15  and  F/A-18.  The  federated  architecture  has  allowed  avionics  systems  to  be  readily 
partitioned  into  separate  sub-systems  that  can  be  separately  developed  as  “commodities”, 
each  with  an  integral  MIL-Std-1553B  interface  capability.  The  multiple  sub-systems  can 
then  be  brought  together  and  integrated  through  use  of  the  standard  multiplex  data  bus.  As 
a  result  of  the  predominant  federated  architectural  approach,  the  Navy  has  created  a 
business  organization  that  is  directly  compatible.  Organizationally,  the  commodity  PMAs 
have  been  created  to  address  the  needs  of  important  separate  or  discrete  functional  areas. 
An  important  examples  is  PMA-209,  Air  Combat  Electronics  which  includes  products  in 
communication,  navigation,  information  systems  and  flight  avionics.  Some  other  examples 
include  PMA-233,  Mission  Planning;  PMA-209,  Aircrew  Systems;  and  PMA-272, 
Electronic  Warfare. 

In  the  last  ten  years  or  so,  the  inadequacies  of  the  federated  architecture  have  become 
apparent.  The  MIL-Std-1553B  data  bus,  primarily  a  control  bus,  has  been  asked  to  carry 
increasing  amounts  of  data.  Its  1  Mb/Sec  bit  rate  is  wholly  inadequate  for  modem  systems 
data  requirements.  Even  for  systems  in  which  Mil-Std-1553  is  retained  as  the  control  bus, 


ms 


it  must  be  supplemented  by  additional  high-speed  buses/networks  to  satisfy  data  transfer 
requirements.  As  a  result  of  this  and  other  trends,  avionics  architectures  have  transitioned 
to  what  is  described  as  a  modular/integrated  architecture.  Figure  5  provides  a  graphical 
representation  of  the  architectural  transition  described. 
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Figure  5.  Graphical  Representation  of  the  Federated  to  Integrated  Architecture  Transition 


As  shown  in  Figure  5,  the  integrated  architecture  is  highly  modularized  and  consists  of 
banks  of  similar  processing  elements.  The  architecture  is  driven  by  advances  in 
microcircuit  integration,  which  today  provides  processing  power  at  a  module  level  that 
once  comprised  a  complete  sub-system  and  required  a  separate  electronic  enclosure.  Rather 
than  utilize  discrete  cabling  between  separate  sub-systems,  integrated  architectures  rely 
heavily  on  module  to  module  transmission  lines  often  packaged  into  module  backplane 
structures.  Such  systems  emphasize  high  pin-count  modular  connectors  with  high 
frequency  signal  transmission  over  controlled  impedance  structures  on  the  backplane.  The 
elements  of  these  architectures  are  closely  coupled  and  highly  interactive.  A  great  deal  of 
architectural  flexibility  is  possible  and  fault  tolerance/avoidance  can  be  built  in  by 


reallocation  of  resources  or  utilization  of  spare  resources  to  minimize  catastrophic  failure 
modes. 

The  nature  of  advanced  modular/integrated  architectures  is  such  that  coordination  between 
avionics  commodity  PMAs  to  agree  on  architectural  structures,  interfaces  and  modular 
standards  would  be  very  helpful.  Such  higher-order  architectural  agreement  would 
promote  a  greater  degree  of  architectural  compatibility  and  functional  interoperability 
between  the  various  products  of  the  avionics  commodity  PMAs.  The  MAIN/MAIL 
laboratory  system  provides  a  facility  to  perform  the  demonstrations  and  system 
integrations  necessary  to  establish  such  common  architectures. 


6.3  System  of  Systems  Avionics 

An  important  role  for  the  MAIL/MAIN  is  to  support  the  integration  process  for  advanced 
avionics  systems.  The  term  “system  of  systems”  has  been  applied  to  large-scale  system 
concepts  at  every  level.  When  applied  to  avionics,  it  has  come  to  indicate  a  number  of 
major  functional  sub-systems  integrated  into  a  single  “super-subsystem”.  System  of 
systems  avionics  integration  takes  advantage  of  advances  in  microcircuit  integration  levels 
(with  circuit  feature  sizes  moving  into  the  sub-micron  level)  and  advances  in  packaging  and 
interconnection  technology.  System  of  systems  avionics  integration  is  applicable  both  to 
new  designs  as  well  as  some  retrofit  applications.  In  retrofit  applications,  advances  in 
microcircuit  integration  allow  an  original  sub-system  enclosure  to  be  replaced  by  an 
updated  enclosure  of  similar  volume.  The  internal  avionics  of  the  updated  enclosure 
consists  of  an  advanced  modular  architecture,  which  combines  multiple  functions  together 
in  the  space  formerly  occupied  by  a  single  function.  The  system  of  systems  approach  is 
therefore  particularly  applicable  to  implement  an  avionics  retrofit/upgrade  architecture. 
Figure  6  illustrates  the  system  of  systems  process  in  s  flow-chart  diagram  form. 
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Integrate  S&T 
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Figure  6.  Avionics  System  of  Systems  Process 


As  shown  in  Figure  6,  the  MAIN/MAIL  system  can  provide  an  integration  framework  to 
support  system  of  systems  avionics  integration.  As  shown,  the  MAIN  &  MAIL  is  utilized 
as  a  development/integration  laboratory  under  direction  of  the  appropriate  avionics  PMA  or 
jointly  under  several  cognizant  avionics  PMAs  representing  the  several  avionics  functional 
areas  being  integrated.  Figure  6  illustrates  how  S&T  research  and  technology  products  can 
be  introduced  and  transitioned  into  the  system  of  systems  product.  As  a  government 
laboratory  resource,  MAIN/MAIL  allows  industry  to  participate  directly  or  through  shared 


CRADAs.  Coherent  system  architectures  can  be  established,  integrating  appropriate  Open 
Systems/COTS  products  as  appropriate.  Coordination  can  be  achieved  between  the 
cognizant  avionics  PMAs  and  the  customer  platform  program  offices  with  MAIN/MAIL 
providing  the  framework  to  resolve  requirements  issues. 


7.0  Status  and  Future  Plans 

This  concept  that  led  to  MAIN/MAIL  implementation  was  first  proposed  in  the  fall  of 
1996.  In  the  Spring  of  1997,  a  leadership  team  was  assembled  from  NAVAIR,  NAWC 
Aircraft  Division  and  NAWC  Weapons  Division,  and  the  project  was  formally  initiated,  In 
July,  1997  a  Request  for  Information  (RFI)  was  issued,  soliciting  information  regarding 
industry  interest  in  the  concept  and  desire  to  participate.  A  number  of  internal  Navy 
briefings  were  given  to  develop  support  and  initial  funding  for  activities  of  the  team.  By 
use  of  video  teleconferencing,  frequent  team  meetings  were  held  and  activities  were 
coordinated  among  the  several  sites.  Development  plans  have  been  formulated  and  several 
preliminary  steps  have  been  completed.  An  assessment  of  available  laboratory  resources  at 
the  three  sites  has  been  performed  and  a  database  has  been  compiled.  Networking  planning 
has  been  initiated  for  the  system.  At  Patuxent  River,  The  AIC  project  has  been  utilized  to 
provide  the  basic  networking  “backbone”  for  that  site.  In  1998  a  number  of  demonstration 
projects  have  been  initiated  to  demonstrate  the  potential  utility  of  the  MAIN/MAIL  system. 

A  business  plan  to  ensure  an  expanded  business  base  for  utilization  of  the  networked 
laboratory  system  is  in  preparation.  Preparation  of  a  Concepts  of  Operations  (CONOPS) 
guide  has  been  initiated  and  will  be  updated  and  revised  as  the  demonstration  projects  are 
completed  and  provide  lessons  learned. 

As  the  system  is  demonstrated  and  implemented,  a  marketing  effort  will  be  put  into  place 
to  expand  the  customer  base.  This  will  include  a  follow-up  RFI  to  industry  to  initiate 
partnering  efforts,  and  CRADA  initiatives. 

As  the  MAIN/MAIL  system  becomes  operational  it  is  expected  that  the  activity  will  be 
made  available  to  other  elements  of  the  AIR-4.0  Engineering  Department,  including  AIR- 
4.1  Systems  Engineering,  AIR-4.6  Crewsystems,  and  AIR-4.7  Weapons  as  well  as  to 
AIR-5.0,  Test  &  Evaluation. 


8.0  Summary  and  Conclusions 

This  paper  has  provided  an  overview  of  the  MAIN/MAIL  initiative  and  its  present 
development  and  implementation  status.  Through  a  discussion  of  its  potential  utilization  we 
have  attempted  to  place  the  significance  of  such  a  capability  into  full  perspective.  As 
discussed,  MAIN/MAIL  can  be  an  important  tool  for  the  NAVAIR  Avionics  Department 
to  satisfy  its  goal  of  greater  coordination  and  unity  throughout  the  Avionics  Competency. 
It  is  expected  that  full  implementation  will  provide  a  laboratory  capability  that  significantly 
enhances  the  Navy’s  ability  to  conceive,  prototype  and  fully  develop  and  integrate  the 
advanced  avionics  systems  required  to  fulfill  future  missions. 
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ABSTRACT 


The  Foundation  Initiative  2010  (FI  2010)  project  is  an  interoperability  initiative  of  the  Director, 
Test,  Systems  Engineering  and  Evaluation,  Office  of  the  Under  Secretary  of  Defense  (Acquisition  and 
Technology),  funded  through  the  Central  Test  and  Evaluation  Investment  Program  (CTEIP).  The  Army 
is  the  lead  service  for  execution,  with  Navy  and  Air  Force  support.  The  FI  2010  effort  is  postured  to 
improve  systems  development,  testing,  training  and  fielding  through  the  application  of  object-oriented 
systems  interoperability  between  simulations,  hardware-in-the-loop  (HITL)  test  laboratories, 
live/operational  tests,  and  training  systems.  The  FI  2010  concept  builds  on  High-Level  Architecture 
(HLA)  and  Test  &  Training  Enabling  Network  Architecture  (TENA)  standards  and  includes  a  core  set  of 
tools,  inter-range  communication  capabilities,  interfaces  to  existing  assets,  a  repository  of  reusable 
software  and  procedures  for  conducting  an  object-oriented  exercise. 

FI  2010  serves  as  the  foundation  upon  which  ranges  will  want  to  build  their  future  investments. 
Therefore,  the  development  strategy  relies  upon  partnering  with  ranges  from  the  beginning,  and  this  is 
accomplished  through  the  creation  of  development  test  cells  and  coordination  with  Range  Commanders 
Council  and  the  Common  Test  and  Training  Range  Architecture  working  groups.  This  paper  provides 
an  overview  of  the  FI  2010  project  and  supplies  details  of  the  objectives  to  be  accomplished  in  FY  98. 
These  include  tests  and  assessments  of  the  simulation  and  federation  object  model  development  tools 
provided  by  the  Defense  Modeling  and  Simulation  Office  and  a  synthesis  of  requirements  for  a  universal, 
flexible  display  engine  with  reusable  components.  They  also  include  a  check-out  of  the  latest  HLA 
runtime  infrastructure  and  a  Hardware-in-the-Loop  to  Open  Air  Range  interaction  investigation  involving 
the  Naval  Undersea  Warfare  Center,  the  Air  Force  Development  Test  Center  and  the  Naval  Air  Warfare 
Center.  A  video  documentary  of  this  investigation  will  be  provided  as  part  of  the  paper  presentation. 


1.0  Introduction 

The  Foundation  Initiative  (FI)  2010  project  responds  to  Defense  Science  Board  recommendations 
to  establish  standards,  facilitate  interoperability,  and  fully  internet  test  and  training  ranges  and  facilities. 


FI  2010  also  responds  to  the  increasing  use  of  Modeling  and  Simulation  (M&S)  in  general  and  to  the 
Simulation  Based  Acquisition  (SBA)  and  Simulate,  Test,  Evaluate  Process  (STEP)  initiative  of  the  Under 
Secretary  of  Defense  (USD)  for  Acquisition  and  Technology  (A&T)  in  particular.  The  architecture  and 
products  delivered  by  FI  2010  are  intended  to: 

1)  Reduce  duplication  and  the  cost  of  procurement  and  maintenance  of  range  instrumentation  and 
software. 

2)  Facilitate  the  integration  of  T&E  and  training  range  assets  across  multiple  ranges. 

3)  Facilitate  the  integration  of  live,  virtual  and  constructive  simulations  to  create  the  larger,  more 
complex,  and  more  realistic  test  and  training  battlespace  environments  demanded  by  modern  weapons 
systems  and  tactics. 

The  FI  2010  Project  was  established  at  the  beginning  of  Fiscal  Year  (FY)  1998  at  the 
recommendation  of  the  Test  and  Evaluation  Reliance  and  Investment  Board  (TERIB).  It  consolidated 
four  existing  Central  Test  and  Evaluation  Investment  Program  (CTEIP)  Projects:  the  Test  and  Training 
Enabling  Architecture  (TENA),  Common  Display  and  Processing  Systems  (CDAPS),  Virtual  Test  and 
Training  Range  (VTTR)  and  the  Joint  Regional  Range  Complex  QRRC).  The  products  and  commodities 
developed  will  entail  concepts  that  foster  extensive  software  reuse,  use  advanced  computational 
developments,  and  exploit  distributed  interactive  simulation  techniques  and  commercial-off-the-shelf 
technologies  (COTS),  where  applicable.  The  products  will  include  sets  of  common,  integrated  software 
capabilities  and  processes  to  significantly  improve  the  capability  to  configure  and  re-configure 
instrumentation  resources  to  acquire,  network,  process,  display,  and  archive  data  in  support  of  T&E 
missions  and  training  exercises. 

The  Full  Operational  Capability  (FOC)  to  be  provided  by  the  FI  2010  architecture  and  products  is 
notionally  referred  to  as  the  Logical  Range — a  set  of  live,  constructive  and  virtual  resources  assembled 
into  a  system  of  systems  to  support  a  specific  test  mission  or  training  exercise.  The  Concept  of 
Operations  (ConOps)  for  the  Logical  Range  is  defined  in  the  document  of  the  same  name  dated  March 
1997  (Draft). 

A  simple  example  of  a  logical  range  is  illustrated  in  Figure  1.  The  Navy  Synthetic  Environment  for 
Tactical  Integration  (SETI)  program  integrates  high  fidelity  torpedo  simulation  capabilities  with  live 
Fleet  submarines  operating  at  depth  and  speed  on  range.  Using  SETI,  a  submarine  can  fire  on  a  live 
target  using  the  Hardware  In  The  Loop  (HWIL)  torpedo  in  the  Weapons  Analysis  Facility  (WAF)  at  the 
Naval  Undersea  Warfare  Center  (NUWC)  Division  Newport.  Both  firing  and  target  submarines  can 
“see”  the  simulated  torpedo  in  real-time  while  submerged  thus  allowing  for  weapons  wire  guidance  and 
target  evasion.  With  planned  connectivity  enhancements  SETI  will  provide  simulated  targets, 
countermeasures  and  ocean  environments.  The  benefits  of  SETI  include  unlimited  availability  of  virtual 
torpedoes  to  support  crew  training  and  torpedo  hit  of  miss  assessments,  capabilities  previously 
unavailable  or  unaffordable. 
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Figure  1.  Synthetic  Environment  for  Tactical  Integration  Exercise 


The  SETI  project  is  one  of  three  FI  2010  exercises  to  be  conducted  in  FY  98.  The  remaining  two 
are  illustrated  in  Figures  2  and  3  below.  Their  purpose  is  to  gain  broad-based  insight  into  the  utility  and 
feasibility  of  conducting  distributed  synthetic  and  live  testing  and  training  events  using  a  common 
architecture  and  reusable  software  tools.  The  FY  98  exercises  focus  on  linking  hardware-in-the-loop 
facilities  and  open  air  ranges,  and  each  investigates  alternative  configurations,  interfaces  and  procedures. 

The  Joint  Advanced  Distributed  Simulation  (JADS)  System  Integration  Test  (SIT)  II  is  a  follow- 
on  to  the  Advanced  Distributed  Simulation  (ADS)  test  conducted  in  FY97  by  the  JADS  Joint  Test 
Force.  Using  HLA  instead  of  a  Distributed  Interactive  Simulation  (DIS)  implementation,  the  JADS  SIT 
II  replicates  the  original  JADS  SIT  risk  mitigation  test  scenario,  linking  the  Pre-flight  Integration  of 
Munitions  and  Electronic  Systems  (PRIMES),  the  Guided  Weapon  Effectiveness  Facility  (GWEF),  and 
the  Central  Control  Facility  (CCF)  at  the  Air  Force  Development  Test  Center,  Eglin  AFB,  FL. 
Operated  and  maintained  by  range  personnel,  a  Development  Test  Cell  (DTC)  emulating  the  Major 
Range  and  Test  Facility  Base  has  been  established  to  cost-effectively  develop,  test,  and  validate  the 
software  interfaces  and  exercise  tools  in  a  controlled  environment.  Toward  our  ultimate  goal  of  range 
interoperability  and  reuse,  the  JADS  SIT  II  exercise  serves  to  be  an  integral  step  -  generating  comparison 
data  to  past  DIS  methodologies,  identifying  potential  HLA  shortfalls  to  be  rectified  by  Test  and 
Evaluation  Enabling  Architecture  (TENA) ,  and  providing  insight  (when  combined  with  results  from 
other  exercises)  to  the  common  aspects  among  ranges  and  facilities  ideal  for  standardization. 


Figure  2.  Joint  Advanced  Distributed  Simulation  (JADS)  System  Integration  Test,  Version  II 


Figure  3.  Simulated  High  Speed  Anti-Radiation  Missile  (SimHARM)  Exercise,  Linking  an 
Installed  Systems  Test  Facility  (ISTF)  to  an  Open  Air  Range  (OAR). 


2.0  The  Need  for  a  New  “Foundation” 


The  conceptual  framework  for  military  operations  defined  in  Joint  Vision  2010  is  of  size, 
scale,  and  scope  that  cannot  be  physically,  technically,  or  economically  recreated  within  the 
existing  DoD  Test  and  Training  infrastructure.  DoD  Test  and  Training  facilities  have  heretofore 
evolved  autonomously,  resulting  in  duplication  of  effort  and  resources,  differing  processes  and 
procedures,  and  wide  variations  in  the  age,  type,  and  capability  of  basic  Test  and  Training 
resources  such  as  instrumentation,  computers,  software,  communication  systems,  and  data 
displays.  These  variations  limit  the  interoperability,  sharing  and  reuse  of  resources  demanded  by 
the  Joint  Vision  paradigm.  In  addition,  the  increasing  use  of  modeling  and  simulation  in  support 
of  acquisition  streamlining  portends  a  new  era  of  duplication  and  disparity  if  a  interoperability 
common  framework  is  not  established  soon.  A  clear  advantage  of  using  modeling  and  simulation 
in  test  and  evaluation  is  the  potential  to  conduct  distributed  operations  across  a  common 
network.  To  make  this  happen,  participating  models  and  simulations  must  have  the  ability  to 
interact,  and  FI  2010  is  charged  with  developing  a  promulgating  the  capabilities  that  will  make 
this  interaction  practical. 


3.0  FI  2010  Architecture  and  Products  Characteristics 

The  FI  2010  architecture  and  products  are  designed  to  support  the  full  spectrum  of  Test 
and  Training  facilities  including  Open  Air  Ranges  (OARs),  Systems  Integration  Laboratories 
(SILs),  Hardware  in  the  Loop  (HWIL)  Facilities,  Measurement  Facilities  (MFs),  Installed 
System  Test  Facilities  (ISTFs),  and  constructive,  live,  and  virtual  Models  and  Simulations. 

Several  characteristics  are  required  to  foster  interoperability,  sharing,  reuse  and  multi- 
domain  polymorphic  applications.  Many  of  these  characteristics  are  key  to  successfully 
implementing  the  logical  range  concept.  All  play  a  role  in  reducing  duplication  and  cost  in  range 
infrastructure  developments  and  in  providing  the  desired  multi-domain  applicability  to  support 
the  full  spectrum  of  Test  and  Training  facilities. 

3.1  Distributability 

The  FI  2010  architecture  and  products  will  support  execution  on  multiple  hardware 
platforms  that  are  geographically  distributed  and  connected  via  one  or  more  communication 
networks.  Multiple  users  will  be  able  to  access  data  from  various  databases  in  order  to  plan 
potential  exercises,  and  will  be  able  to  query  potential  participants  about  their  availability  and 
current  or  projected  operational  capabilities. 


3.2  Extensibility 

The  architecture  will  also  allow  LR  components  to  be  easily  upgraded  or  modified  to 
support  add-on  requirements  without  requiring  restructuring  of  the  existing  architecture.  Add¬ 
ons  could  include  providing  more  and/or  different  workstations  from  which  planning  and  exercise 
control  would  be  conducted,  incorporating  new  data  networks,  including  new  sensors,  and 
weapons  and/or  models  to  simulate  them,  etc. 

3.3  Interoperability 

Systems,  units,  or  forces  must  be  able  to  provide  and  receive  services  from  other  systems, 
units  or  forces,  and  to  use  the  services  such  that  they  can  operate  together  effectively. 
Interoperability  is  a  system  characteristic,  which  allows  the  assets  of  one  test  or  training  facility 
to  be  used  and  controlled  by  one  or  more  other  facilities  “on  demand”;  as  seamlessly  as  if  they 
were  an  integral  part  of  their  organic  systems. 

3.4  Modifiability 

The  FI  2010  architecture  and  products  will  support,  to  the  maximum  extent  possible,  the 
ability  of  a  hardware  or  software  component  to  be  easily  modified  to  perform  various  tasks,  to 
operate  within  new  systems  or  environments,  or  to  adapt  to  changes  in  scope  or  magnitude  of 
performance  requirements.  Modifiability  often  depends  on  an  item’s  modularity  and  use  of 
standard  interfaces  and  is  normally  more  easily  achieved  with  software.  As  an  example,  to  be 
modifiable  the  simulation  of  a  sensor  or  weapon  system  must  provide  for  the  various 
performance  parameter  values  to  be  determined  by  preset  and  easily  changeable  data  files/tables 
rather  than  “hard”  coded. 

3.5  Portability 

This  is  the  ability  of  a  system,  hardware  or  software  component,  or  data  to  be  easily 
transferred  from  one  hardware  or  software  environment/system  to  another.  This  requires  the 
existence  and  use  of  common  interfaces  so  that  hardware/software  components  and  data  can  be 
easily  inserted  into  various  environments/systems  with  minimal  reformatting  or  interface 
modification.  FI  2010  will  assist  in  the  development  of  commercial  standards  to  promote 
development  of  common  interfaces  needed  for  portability. 

3.6  Reusability 

Reusability  is  the  ability  to  use  the  same  products  and  capabilities  at  multiple  ranges  and 
facilities.  An  example  product  might  be  a  graphical  display  software  package.  Other  examples 
may  include  processes,  procedures  and  documentation  templates  (e.g.,  design,  test,  standards). 
Reuse  supports  a  common-core  of  a  product  that  is,  in  fact,  exactly  the  same  from  instance  to 
instance  of  that  product,  and  it  also  supports  the  ability  to  adapt  the  reusable  product  in 
predetermined  ways  at  the  level  of  a  local  instance.  Reuse  is  distinct  from  commonality  in  that 
commonality  implies  every  instance  of  the  reused  product  is  exactly  the  same.  Effective  reuse  is 
an  optimization  of  commonality  and  flexibility  that  recognizes  the  unique  requirements  of 
individual  ranges  and  facilities  within  a  common  core  environment  or  domain.  Reuse  enables 
significant  savings  in  long-term  development  and  maintenance  costs  and  is  an  effective  and 
efficient  path  to  sharing  and  interoperability. 


3.7  Scaleability 

Scaleability  is  the  ability  to  use  the  same  architecture  and  application  software  on  many 
different  classes  of  hardware/software  platforms  from  personal  computers  to  supercomputers 
and  for  tasks  varying  in  scope  and  complexity  (extends  the  portability  concept).  The  capability 
to  handle  various  operations  of  greatly  different  scales  of  operational  requirements  and  to  be  able 
to  easily  grow  to  accommodate  increased  workloads  beyond  the  initial  capability.  An  example  of 
scaleability  in  the  LR  context  is  to  be  able  to  run  a  single  vehicle  exercise  at  a  single  range  or  a 
multi-vehicle  exercise  at  multiple  ranges  and  other  facilities  with  the  same  basic  system. 

3.8  Sharability 

The  FI  2010  architecture  and  products  shall  support  sharing  which  is  defined  as  the 
ability  of  one  facility  to  directly  use  the  products  generated  by  another  facility.  Interoperability 
is  the  most  extensive  form  of  sharing,  but  is  not  the  only  form.  This  definition  of  sharing 
includes  a  variety  of  “one-way”  information  exchanges  where  data  or  data  products  are  sent  to 
many  facilities,  but  control  of  the  data  generation  is  strictly  at  one  source.  An  example  of  this 
capability  is  the  effective  transmission  of  post-test  analysis  products  without  custom  translation 
required  for  each  product  user. 

3.9  Usability 

The  FI  2010  products  will  enable  the  LR  users  to  perform  their  tasks  effectively  and 
efficiently.  A  usable  system  is  can  be  used  by  a  variety  of  system  operators  for  a  variety  of 
tasks.  Although  operators  may  have  unique  or  specialized  skills  (e.g.  test  conductors,  flutter 
engineers,  graphics  operator,  etc.),  they  should  not  need  special  training  to  use  those  skills  via 
standard  system  interfaces.  Operator  interfaces  will  be  “friendly,”  and  operators  will  be  able  to 
perform  their  tasks  following  the  instructions  and  guidance  provided  in  manuals  or  on-line  help. 
Operator  entries  will  be  by  point  and  click  (mouse,  track  ball,  etc.),  pull-down  menu  selection, 
keyboard,  or  other  simple  interface  device. 

4.0  Operating  a  Logical  Range 

The  FI  2010  architecture  and  products  will  support  the  ability  to  rapidly  define,  setup 
and  execute  a  logical  range  and  its  associated  battlespace  environment  for  a  test  mission  or 
training  exercise  by  assembling  and  managing  the  necessary  resources  from  a  pool  of  available 
live,  constructive,  and  virtual  resources.  Regardless  of  whether  the  particular  resources  used  for  a 
given  event  are  actual  or  simulated,  the  objectives  of  the  event  are  the  same:  to  accurately  test  and 
/  or  evaluate  the  performance  of  a  system  under  test  (SUT)  or  training  participant  under  a  certain 
set  of  conditions.  This  is  accomplished,  usually  in  a  stand-alone  mode  today  through  the  use  of 
numerous  T&E  and  Training  support  resources  known  commonly  as  OARs,  SILs,  HWIL 
facilities,  MFs,  ISTFs,  and  M&S  facilities.  Meeting  the  objectives  of  reducing  duplication, 
facilitating  the  integration  of  T&E  and  training  range  assets,  and  facilitating  the  integration  of  live, 
virtual,  and  constructive  simulations  requires  that  the  capabilities  to  define,  setup  (configure),  and 
operate  the  assets  (e.g.,  instrumentation,  environment  generators,  stimulators)  be  drawn  from  a 
common  framework.  This  is  also  true  for  the  assets  used  in  conducting  post-event  analysis. 


4.1  Defining  a  Logical  Range 

Current  methods  of  defining  the  specific  assets  of  T&E  and  Training  support  resources 
are  predominantly  unique  to  the  particular  resources  being  considered.  Referring  back  to  the 
SETI  experiment  as  an  example,  the  means  for  defining  what  torpedo  information  needs  to  be 
available  during  the  conduct  of  that  exercise  (e.g.,  speed,  heading,  position)  would  be  different  for: 
an  actual  firing  of  a  torpedo  at  AUTEC  (underwater  ‘OAR’),  a  simulated  torpedo  launch  in  the 
WAF  (HWIL  facility),  or  a  synthetic  torpedo  launch  in  a  M&S  facility.  This  could  potentially 
be  true  for  all  of  the  participants  required  for  a  particular  LR  instance  (i.e.,  test  mission  or 
training  event).  Recognizing  that  the  cost  of  defining  the  assets  required  for  a  logical  range 
operation  must  be  significantly  less  than  the  current,  aggregate  cost  of  defining  these  assets  for 
stand-alone  operations,  the  logical  range  will  provide  the  definition  capabilities  as  described 
below.  These  capabilities  will  be  common  among  the  various  resources  being  assembled  for  a 
logical  range  operation  and  transparent  to  the  user  with  respect  to  the  specific  resource  from 
which  the  asset  is  being  identified  (eg.,  OAR,  HWIL,  or  M&S  based). 

Resource  Asset  Identification.  This  identification  capability  includes  asset  attributes 
such  as  name,  type,  location,  input  data,  and  output  data.  An  example  of  a  resource  asset  would 
be  a  radar  (of  type  FPS-16  with  output  data  of  range,  azimuth,  elevation,  and  time). 

Resource  Asset  Definition.  A  logical  range  resource  asset  definition  allows  a  logical  range 
operation  planner  to  define,  where  necessary,  the  operation  unique  resource  asset  information. 
An  example  of  such  an  asset  would  be  a  telemetry  system.  The  format  of  the  input  stream,  the 
processing  to  be  applied  to  each  raw  data  item  decommutated  from  the  stream,  and  the 
engineering  units  of  the  resulting  data  items  are  specific  to  a  particular  logical  range  operation. 

Resource  Repository.  This  repository  shall  includes  typical  data  base  capabilities  to 
store,  search,  retrieve,  copy,  and  modify  entries.  Entries  will  consist  of  the  resource  asset 
identification  and  definition  information.  It  will  also  ensure  that  information  is  provided  in  a 
FI2010  compliant  format. 

Resource  Browser.  A  resource  browser  capability  allows  remote  access  to  the  resource 
repository.  This  access  capability  will  be  available  via  existing  community  desktop  computer 
systems  (i.e.,  no  logical  range-specific  or  unique  equipment). 

Logical  Range  Definition  Capability.  This  includes  the  means  to  assemble  resource  assets 
from  the  resource  asset  repository  in  accordance  with  the  specific  requirements  of  a  mission  or 
exercise.  It  includes  the  capability  to  designate  primary  and  secondary  resource  assets  to 
accommodate  the  rapid  reconfiguration  of  a  logical  range  due  to  failures  and  scheduling  conflicts 
associated  with  designated  primary  resource  assets  during  LR  operations. 

Logical  Range  Repository.  This  repository  will  include  typical  data  base  capabilities  to 
store,  search,  retrieve,  copy,  and  modify  entries.  These  entries  will  consist  of  logical  range 
instances  stored  via  the  logical  range  definition  capability.  It  shall  also  ensure  that  information  is 
provided  in  a  FI2010  compliant  format. 

Logical  Range  Definition  Utilities.  The  following  utilities  will  be  provided  to  support  the 
logical  range  definition  capability: 

Performance  Prediction.  This  utility  shall  analyze  the  resource  asset  interactions  defined 


for  a  particular  operation  and  identify  potential  performance  discrepancies.  This  shall  include 
items  such  as  network  bandwidth,  missing  data  items,  mismatched  data  item  formats,  and 
mismatched  data  rates.  Using  the  SETI  experiment  as  an  example,  the  position  of  the  launching 
submarine  would  be  identified  as  a  missing  data  item  were  it  not  defined  for  the  AUTEC  range 
asset  as  it  is  a  required  input  to  the  torpedo  systems  of  the  WAF  asset.  A  mismatched  data  item 
format  would  be  detected  if  the  AUTEC  range  asset  defined  the  submarine’s  depth  in  feet  when 
the  WAF  is  defined  to  accept  it  in  meters. 

Network  Simulation.  This  capability  provides  the  means,  based  upon  the  resource  assets 
and  network  assets  defined  for  a  particular  LR  operation,  to  simulate  the  planned  LR  network. 
This  simulation  capability  provides  the  user  with  the  capability  to  identify  potential  bandwidth, 
latency,  protocol,  and  general  LR  asset  interaction  discrepancies  of  the  actual  operation  but 
without  directly  utilizing  the  physical  resources. 

Logical  Ranee  Configuration  File  Generation.  This  capability  generates  the  files  required 
to  configure  the  assets  for  a  specific  logical  range  defined  within  the  logical  range  repository  and 
selected  by  the  user. 

4.2  Logical  Range  Setup 

Logical  Range  Setup  capabilities  will  include: 

a.  Scheduling.  Scheduling  capabilities  facilitate  planning  for  the  execution  of  an  exercise  or 
test  on  the  logical  range.  Scheduling  capabilities  will  accommodate,  to  the  maximum 
extent  practical,  the  various  scheduling  and  accounting  systems  in  use  at  DoD  and 
contractor  ranges  and  facilities. 

b.  Network  Setup  Support.  The  Network  Setup  Support  Capability  will  support  the 
translation  of  the  logical  network  defined  during  the  logical  range  definition  phase  into  the 
physical  network  required  to  execute  the  logical  range  task.  The  Network  Setup  Support 
Capability  will  also  support  testing  of  the  physical  network  prior  to  execution. 

Test  Capabilities  will  include: 

1)  Component  Compliance  Test.  This  capability  will  be  used  to  support  testing  of 
each  simulation  for  compliance  with  its  definition  and  with  the  definition  for  the 
logical  range  before  interaction  is  attempted  with  external  simulations. 

2)  One-on-one  Interaction  Testing.  One-on-one  Interaction  Testing  capabilities  will 
support  testing  the  interactions  between  each  pair  of  components  in  the  logical 
range  definition  to  ensure  that  interactions  occur  as  expected. 

3)  Manv-on-manv  Interaction  Testing.  Many-on-many  Interaction  Testing 
capabilities  will  support  testing  the  interactions  that  are  expected  between 
components  in  the  exercise  environment. 

4)  End-to-end  Testing.  End-to-end  testing  capabilities  will  support  testing  the 
interactions  of  all  resources  in  the  logical  range.  End-to-end  testing  is  a  complete 
rehearsal  of  the  test/training  exercise  scenario. 


4.3  Logical  Range  Execution  Management 

Logical  Range  Execution  Management  will  include: 


a.  Logical  Range  Control.  Logical  range  control  capabilities  will  provide  for  human  control, 
monitoring,  and  visualization  of  the  LR  during  the  execution  of  its  resources.  These 
include  Resource,  Network,  Initialization,  and  Execution  applications. 

b.  Logical  Range  Monitors.  Monitors  support  the  Control  capabilities  and  will  support 
monitoring  the  real-time  operation  of  the  logical  range.  Logical  range  monitors  include: 

1)  A  Network  Traffic  Monitor  to  display  status  and  control  the  flow  of  messaging  on 
the  logical  range  network. 

2)  A  Message  Monitor  to  monitor  and  keep  track  of  the  message  traffic  between  the 
various  resources  of  the  logical  range. 

3)  A  Data  Monitor  to  track  the  data  being  captured,  perform  quality  checks,  and  display 
data  on  request. 

c.  Visualization  Capabilities.  Visualization  capabilities  will  support  the  display  of  standard 
tactical,  three-dimensional  viewport,  and  graphical  data  and  events  and  are  used  both  for 
real-time  visualization  of  events  and  post-test  review  and  analysis. 

d.  Data  Logging  and  Archiving.  Data  logging  and  archiving  capabilities  will  support  the 
capture  and  storage  of  data  for  playback  and  analysis. 

4.4  Post  Test  Mission  /Training  Exercise  Analysis 

Post  Test  Mission  /Training  exercise  analysis  capabilities  will  include  Playback,  Data 
Extraction,  Visualization,  and  Data  Definition  capabilities: 

a.  Playback  Capability  to  reconstruct  exercise  or  test  events  from  messages  and  data  logged 
during  the  execution  of  the  logical  range. 

b.  Data  Extraction  Capability  to  extract  specific  data  elements  or  events  selected  from  the 
data  logged  during  the  execution  of  the  logical  range. 

c.  Visualization  Capabilities  to  support  data  analysis  uses  the  same  visualization 
capabilities  used  for  logical  range  execution  management. 

d.  Data  Definition  Capabilities  used  to  characterize  the  data  during  the  logical  range 
definition  phase  also  support  post  test/exercise  analysis. 

5.0  Summary  &  Conclusion 

Obviously,  the  task  of  reinventing  the  test  and  training  infrastructure  is  not  for  the  faint  of  heart. 
The  technical  issues  are  vast  and  complex,  but  they  are  meager  relative  to  the  cultural  and 
organizational  issues,  which  this  paper  does  not  begin  to  address.  There  indications,  however, 
that  the  time  may  be  right  to  begin  the  discussion.  The  Defense  Modeling  and  Simulation  Office 


(DMSO)  High  Level  Architecture  (HLA)  and  other  DoD  M&S  initiatives,  such  as  the  Synthetic 
Environment  Data  Representation  &  Interchange  Specification  (SEDRIS),  the  Modeling  and 
Simulation  Resource  Repository  (MSRR),  and  the  Master  Environmental  Library  (MEL)  are 
positive  steps  toward  improved  interoperability.  In  addition,  DoD  Manual  8320.1-M-l,  Data 
Standardization  Procedures,  dated  November  1996  (Draft)  and  the  DoD  Range  Commander’s 
Council  (RCC)  Data  Interchange  Standard,  DR-19,  are  important  resources  for  achieving  this  end, 
as  the  Joint  Technical  Architecture  (JTA)  and  Defense  Information  Infrastructure  (DII)  Common 
Operating  Environment  (COE). 

Initial  Operating  Capability  (IOC)  for  FI  2010  is  defined  as  the  completion  of  a  Joint 
Test  Exercise  (JTE)  that  successfully  demonstrates  the  FI  2010  architecture  and  core  set  of 
products.  However,  during  the  execution  of  the  FI  2010,  products  supporting  the  functionality 
of  the  LR  will  be  developed  and  delivered  incrementally  to  the  ranges  and  facilities.  Full 
Operational  Capability  (FOC)  is  to  be  determined;  however,  it  is  anticipated  the  FI  2010 
architecture,  products  and  the  logical  range  concept  of  operations  will  continue  to  evolve 
indefinitely  after  IOC,  funded  by  non-CTEIP  mechanisms. 
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Abstract 

This  paper  describes  ongoing  efforts  by  the  Avionics  Systems  Integration  Branch,  Naval 
Air  Warfare  Center  Aircraft  Division,  Patuxent  River,  Maryland  to  integrate  wearable  computers, 
into  an  aircraft  maintenance  environment.  This  Hands-Free  Avionics  Maintenance  System 
(HAMS)  includes  state-of-the-art  technologies  such  as  voice  recognition,  wireless  Internet 
services  and  remote  video  teleconferencing. 

The  aircraft  maintenance  system  also  entails  converting  the  existing  paper  based  legacy 
data,  i.e.,  technical  manuals  and  maintenance  record  cards  (MRC’s)  into  electronic  data  stored  on 
an  Internet  server.  This  data  would  be  organized  and  accessible  by  the  various  maintenance  tasks 
performed  and  multimedia-enhanced,  providing  the  technician  with  text,  graphics,  video  and 
animation.  The  same  multimedia  database  could  then  be  used  to  both  train  the  Aircraft 
Maintenance  Technician  (AMT)  and  to  assist  the  AMT  on  the  flight  line  performing 
maintenance  procedures. 
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I.  Introduction 


The  Naval  Air  Warfare  Center  at  Patuxent  River,  MD  is  developing  an  integrated  system  to 
support  the  diagnosis  and  repair  of  aircraft  that  utilizes  wearable  computers  for  the  U.S.  Navy. 
Specifically,  the  development  team  is  working  to  bring  aircraft  Interactive  Electronic  Technical 
Manuals  (IETM’s),  electronic  maintenance/inspection  procedures  and  video  teleconferencing  to 
the  flight  line  for  the  first  time.  This  combination  of  wireless,  wearable  technical  data,  distributed 
via  Internet  from  a  central  site  and  “expert”  aviation  diagnostic  and  repair  advice  dispensed  to 
geographically  remote  sites  via  teleconferencing  enables  repair  of  aircraft  and  their  complex 
avionics  subsystems  independent  of  the  squadron’s  deployed  location.  The  anticipated  benefits 
of  this  effort  will  be  a  reduction  in  maintenance  and  repair  times,  improved  aircraft  availability, 
and  a  reduction  in  the  support  cost  factors  associated  with  the  aircraft  flight  line  maintenance 
activities  and  document  distribution. 

II.  The  Need  for  Improved  Maintenance  Practices 

Navy  avionics  maintenance  is  currently  a  paper  and  manpower  intensive  process. 
Technical  manuals,  daily  and  periodic  maintenance  check  lists  are  all  distributed  via  print  media 
(paper  and  laminated  card  stock).  As  document  printing  and  publishing  budgets  continue  to  be 
reduced  and  as  warehousing  costs  for  paper  documents  continue  to  rise,  printed  documents  are 
updated  and  distributed  less  and  less  frequently.  The  conversion  to  digital  media  will  mitigate 
these  problems  along  with  providing  updates  in  a  more  timely  fashion. 

Current  manpower  issues  center  on  the  cost  of  sustaining  “subject  matter  experts”  at  each 
squadron  location.  Historically,  whenever  a  squadron  encounters  a  problem  beyond  the 
capabilities  of  the  organic  maintenance  staff,  the  “experts”  are  consulted  on  the  site.  At  remote 
sites  the  squadrons  often  lose  the  services  of  many  of  their  field  service  representatives  who  are 
located  in  the  U.S.  These  “experts”  advise  the  squadron  during  their  more  complicated 
maintenance  tasks  but  are  not  routinely  deployed  to  remote  locations.  If  complex  problems  arise 
a  “tiger  team”  is  dispatched  to  address  them.  As  maintenance  budgets  also  decline,  the  Navy  is 
facing  the  challenge  of  finding  alternatives  to  the  dispatching  of  “expert  tiger  teams”  and  to 
sustaining  “expert”  staff  at  each  U.S.  based  location.  The  Avionics  Systems  Integration  Branch 
anticipates  the  wireless  wearable  Web  services  will  assist  the  Navy  in  addressing  both  the  paper 
and  manpower  issues.  Based  on  the  prototype  system  that  we  have  developed,  we  anticipate 
that  a  wearable  computer  system  with  network  connectivity  will  provide  the  required 
functionality  and  performance  at  a  cost-effective  price. 


The  HAMS  concept  addresses  two  major  needs.  The  first  is  Affordability:  the  HAMS 
will  meet  the  need  to  develop  systems,  processes  and  technologies  that  result  in  reduced 
manpower.  The  HAMS  will  also  meet  the  need  to  develop  new/improved  maintenance 
techniques  and  processes  -  with  on-line  technical  assistance  at-sea  and  ashore.  The  second  is 
Information  Support:  the  HAMS  will  meet  the  need  to  develop  techniques  to  increase  the 
portability  of  computer-based  maintenance  and  training  systems. 

The  requirement  to  reduce  operations  and  support  costs  is  universal  across  all  aircraft 
platforms.  Reduction  of  these  costs  at  the  organizational  level  with  the  use  of  the  HAMS  would 
provide  a  sizable  cost  saving.  The  Navy  has  started  the  process  to  provide  Interactive  Electronic 
Technical  Manuals  (IETM’s)  for  the  maintenance  technician.  However,  IETM’s  on  laptop 
computers  still  miss  the  mark  with  problems  such  as  sunlight  readability,  probability  of  being 
dropped  and  are  generally  inconvenient  to  use.  While  newly  developed  flat  screen  displays  that 
do  very  well  in  bright  sunlit  areas  are  within  a  year  of  being  introduced,  an  important  requirement 
is  not  achieved.  That  requirement,  to  allow  maintenance  personnel  to  have  the  data  they  require 
and  at  the  same  time  not  restrict  their  maintenance  actions  by  tying  their  hands  to  a  PC  or  flat 
panel  display  is  addressed  by  the  HAMS  concept. 

Several  portable  computer  technologies  support  the  concept.  Laptop  devices,  including 
rugged  versions,  can  provide  access  to  technical  information  and  be  linked  via  wireless  LAN 
configurations  to  information  and  personnel.  However,  only  the  body  worn  (“wearable”) 
computers  afford  “hands-free”  access  and  control,  providing  complete  mobile  functionality  (see 
Figures  1,  2  and  3).  The  wearable  together  with  voice  recognition  software  and  high-resolution 
displays  worn  over  the  eye  or  mounted  on  the  body  will  produce  a  truly  hands-free  environment. 
For  example,  the  AMT  can  “ask”  the  computer  for  a  torque  rating  of  a  particular  bolt,  and  receive 
a  response  form  the  computer,  while  keeping  both  of  his  hands  on  the  torque  wrench.  Both  the 
hardware  and  software  for  wearable  systems  has  evolved  to  provide  the  required  levels  of 
functional  performance  and  affordability.  Similarly  the  wireless  LAN  components  have  matured 
to  the  point  where  they  may  be  considered  as  both  cost  effective  and  functionally  acceptable. 
Realization  of  the  concept  requires  the  adaptation  and  integration  of  these  diverse  elements  to 
achieve  a  system  support  tool  that  will  amplify  the  effectiveness  and  results  of  the  individual 
maintenance  technician  and  inspector  in  carrying  out  their  assigned  duties. 


Figure  1 
Via,  FlexiPC 


III.  System  Description 

A  high  level  pictorial  of  the  Tele-maintenance  Concept  is  depicted  in  Figure  4,  Hands- 
Free  System  Maintenance  System  Concept.  This  figure  portrays  the  AMTs  equipped  with  the 
HAMS  units,  linked  with  the  maintenance  shop  via  wireless  LAN,  which  in  turn  is  supported  by 
other  logistics  systems  and  communication  links  to  the  Internet  and  remote  technical  support 
systems  and  personnel. 

Hands  Free  Maintenance  System  Concept 


Maintenance  Office 


Figure  4 

The  HAMS  will  provide  a  portable  integrated  inspection  and  maintenance  support 
system  for  the  AMT’S  using  wearable  computing  devices,  voice  recognition  software,  wireless 
communication  links,  operational  software  and  interfaces  to  legacy  support  systems.  The  heart 
of  the  HAMS  is  a  lightweight  state-of-the-art  wearable  computer,  which  contains  a  3GB+  Hard 
drive,  64MB  RAM,  wireless  PCMCIA  card  for  LAN/Internet  connectivity,  display,  microphone 
and  a  earpiece  speaker. 

As  with  any  new  system,  the  most  critical  and  costly  element  is  the  development  of  the 
software.  In  the  case  of  Avionics  maintenance,  the  majority  of  information  is  contained  in  paper- 
based  manuals  and  MRC’s  that  will  need  to  be  converted  to  an  electronic  based  format.  In  the 
few  instances  where  platforms  have  electronically-based  manuals,  we  are  faced  with  developing 
one  of  a  kind  transition  tools  to  convert  proprietary  software.  Fortunately,  the  NAWC  has 
funded  an  SBIR  with  Via,  Inc.  that  has  identified  some  of  these  problems  and  developed  tools 
that  can  be  used  to  convert  the  proprietary  software. 

The  choice  of  software  in  which  avionics  maintenance  information  will  be  contained  is 
certainly  the  most  critical  decision.  Past  lessons  learned,  point  to  the  fact  that  proprietary 


systems  are  the  most  costly  to  maintain.  It  is  critical  that  the  software  used  in  the  HAMS  is 
accepted  as  a  worldwide  standard.  At  the  recent  (May,  1998)  NetWorld+Interop,  UUNet 
Technologies,  Inc.  President  and  CEO,  John  Sidgmore  cited  in  his  keynote  address  that  Internet 
traffic  is  at  a  1,000  percent  growth  rate.  Mr.  Sidgmore  stated  that  he  believed  that  Internet  traffic 
would  soon  consume  half  the  available  bandwidth  on  networks  worldwide.  By  2002,  the 
percentage  will  climb  to  90  percent,  and  in  2008  Internet  traffic  will  account  for  99  percent  of  the 
data  traversing  international  networks.  While  it  is  impossible  to  predict  the  future,  we  believe 
Mr.  Sidgmore  is  going  to  be  on  the  mark.  There  should  be  no  doubt  that  any  database  that  is 
assembled  for  avionics  maintenance  should  be  designed,  stored  and  accessed  on  an 
Internet/Intranet  server.  As  aircraft  manufacturers  develop  their  information  in  electronic  formats 
such  as  scanned  images,  word  processing  outputs,  tagged  data  files  (SGML,  HTML),  the  Navy 
must  be  able  to  accommodate  these  documentation  variants  into  its  own  structure.  The  HAMS 
will  integrate  legacy  manuals  and  documentation  into  portable  and  accessible  Internet  readable 
electronic  formats,  and  augment  the  information  with  Internet  friendly  audio,  video,  graphics,  and 
various  viewing  aids. 

For  inspection  purposes,  the  HAMS  system  will  display  Maintenance  Requirement  Card 
(MRC)  procedures  and  provide  for  the  entry  of  data  and  text  inputs.  MRC’s  will  be  displayed 
on  the  wearable’s  display  monitor  with  all  attendant  required  documentation.  Each  procedure  will 
require  compliance  and,  where  defined,  electronic  signature  verification  or  approval  from  pre¬ 
assigned  validations  and  supervisors.  Support  documentation,  such  as  Operator’s  Manuals,  will 
be  available  in  electronic  format.  Just-In-Time  training  video  clips  for  primary  procedures  will  be 
available.  Completed  inspection  scenarios  will  be  uploaded  via  wireless  communication  networks 
directly  from  the  flight  line  to  a  local  inspection  data  base. 

For  maintenance  purposes,  the  HAMS  system  will  provide  computerized  assistance  in 
determining  causality  from  accumulated  symptoms.  This  assistance  will  be  provided  in  the  form 
of  decision  trees  as  presently  structured  manually  within  existing  Maintenance  Manuals,  and 
eventually  evolve  into  expert  rule  based  algorithms  for  specified  equipment  types.  The  HAMS 
can  also  support  detailed  problem  data  collection  and  analysis  through  the  use  of  plug-in  modules 
that  provide  direct  connection  to  digital  data  bus  message  traffic  and  measure  electronic  signal 
characteristics.  Advanced  capability  will  provide  for  the  direct  interfacing  of  the  HAMS  to  a 
digital  data  bus  for  evaluating  mission  avionics  status.  Discrepancy  reports  can  be  downloaded 
directly  from  the  local  data  base  on  the  flight  line  through  the  use  of  wireless  communication 
links.  Automatic  logging  of  maintenance  actions  and  parts  used  will  be  a  system  capability. 

IV.  Benefits 

The  aviation  community,  both  civilian  and  military,  has  recognized  the  need  to  change 
their  current  maintenance  techniques  and  move  toward  more  cost-effective  alternatives. 
Contemporary  maintenance  methods  and  programs  are  driven  by  factors  of  cost  and  performance 
integrity.  New  approaches  that  fare  favorably  in  a  cost/  benefit  analysis  will  receive  primary 
consideration  for  implementation.  Consequently  any  device,  procedure  or  system  that  can 
address  cost  and  performance  issues  will  receive  due  consideration.  The  Avionics  Systems 


Integration  Branch  has  determined  that  the  use  of  wearable  computers  to  support  the  HAMS 
concept  presents  significant  cost  reduction  opportunities  and  enhances  compliance  levels  for 
safety  related  inspection/repair  procedures. 

The  introduction  of  wearable  computers  to  U.S.  Navy  aviation  maintenance  sites  is  expected 
to  positively  impact  affordability  in  seven  specific  areas: 

(1)  Reduce  inspection  manpower  for  scheduled  inspections 

(2)  Reduce  inspection  skill  level  requirements. 

(3)  Reduce  flight  line  maintenance  manpower  for  normal  maintenance  and  repair  actions 

(4)  Reduce  mean  time  to  repair. 

(5)  Reduce  logistic  support  manpower  levels. 

(6)  Decrease  maintenance  training  costs. 

(7)  Reduce  flight  line  parts  sparing  levels. 

The  Tele-maintenance  concept  in  conjunction  with  wearable  computers  offers  a  dramatic 
potential  for  performance  enhancement  of  maintenance  personnel.  A  variety  of  factors 
contribute  to  the  performance  improvements,  including  several  already  identified  as  cost  factors. 
No  one  factor  appears  to  dominate  the  list,  however,  controlled  studies  currently  underway  will 
provide  hard  metrics  to  validate  the  perception.  However,  immediate  and  obvious  advantages  to 
Tele-maintenance  include  both  reduced  numbers  and  skill  levels  of  personnel.  Currently 
situations  arise  where  multiple  maintenance  personnel  are  required  simply  because  of  the  work 
location  and  the  attendant  need  to  access  maintenance  documentation  or  information.  Wearable 
computers  in  a  “hands  free”  operating  mode  have  been  demonstrated  to  reduce  the  need  for 
additional  staff  in  most  situations.  In  addition  the  access  to  amplifying  information  and  Just  in 
Time  Training  (JITT)  in  the  form  of  “show  me”  videos  or  graphics  supports  the  use  of  less 
experienced  personnel,  even  for  more  complex  tasks.  An  associated  feature  of  this  approach  is 
the  ability  to  reduce  the  formal  training  requirements  for  staff  resulting  in  both  reduced  training 
costs  and  expedited  availability  of  maintenance  personnel  to  the  field. 

Procedural  consistency  is  promoted  by  hosting  procedures,  checklists  and  forms  on  the 
wearable  computer,  and  controlling  the  order,  data  access  and  monitoring  of  the  inspection  and 
maintenance  processes.  Both  results  and  performance  metrics  can  be  acquired  to  support  the 
establishment  of  training  requirements  and  procedure  modifications.  Furthermore,  access  to  a 
centralized  database  can  be  used  as  a  means  to  promote  the  expedited  update  to  procedures  and 
documentation,  and  the  accelerated  distribution  of  corrected  information. 

It  is  recognized  that  the  wearable  computer  has  a  powerful  role  in  affording  access  to 
information  and  accommodating  diagnostic  tools  such  as  plug-in  test  equipment  and  data  bus 
analyzers,  and  local  “expert”  system  support  programs.  However,  the  Tele-maintenance  concept 
elevates  the  role  of  the  wearable  computer  to  another  dimension  by  affording  a  real  time  link  to 
maintenance  experts  at  the  design  and  manufacturing  levels  of  the  system  under  evaluation. 


Through  video  conferencing  the  systems  experts  can  be  literally  at  the  side  of  the  maintenance 
technician  supporting  the  diagnosis  and  repair  of  the  system  under  test.  This  is  expected  to  have 
an  amplifying  effect  on  the  performance  levels  of  the  field  personnel  for  those  problems  that  are 
beyond  the  routine. 


V.  Current  Technology  Challenges 

The  Wearable  PC  shown  below  in  figure  5  is  the  Via  III.  It  is  a  future  generation  wearable 
PC  on  a  belt  that  contains  a  Pentium  class  processor.  This  is  only  one  example;  Companies  such 
as  Interactive  Solutions  and  Xybernaut  will  surely  follow  in  developing  small  wearable  PC’s. 
While  it  is  easy  to  envision  a  wide  array  of  uses  for  the  wearable  PC,  several  related  technologies 
will  need  to  grow  before  we  reach  the  wide  spread  use  of  the  wearable. 


Figure  5 


Via  III 


A.  Wearable  PC’s 

The  keystone  of  our  efforts  is  the  wearable  PC.  In  the  almost  three  years  that  we 
have  worked  with  wearable  PC’s,  a  marked  change  has  occurred.  The  wearable  has  been  reduced 
in  size  and  weight  by  almost  fifty  percent.  The  processor  has  gone  from  a  486-33MHz  to  a 
Pentium  133  MMX,  to  the  recently  announced  233MHz  Pentium  II  Mobile  chip.  Memory  has 
increased  from  24MB  to  64MB  and  disk  drives  have  gone  from  500MB  to  3.1GB. 

While  the  above  are  all  major  enhancements,  manufacturers  must  work  to  dissipate 
the  heat  generated  by  the  high-speed  Pentium  chip.  The  Pentium  CPU  has  provided  the  wearable 
PC  with  the  processor  speed  needed  to  handle  a  variety  of  tasks,  particularly  in  the  area  of  voice 
recognition.  Unfortunately,  the  tremendous  increase  in  CPU  speed  has  caused  a  great  increase  in 
temperature.  During  our  testing,  we  have  recorded  temperatures  as  high  as  140-degree  on  the 
surface  of  the  wearable  PC.  While  Intel  has  stated  that  the  Pentium  can  run  at  130-degree 
temperatures  and  above,  recent  versions  of  the  chip  have  required  laptop  manufacturers  to  install 
up  to  four  small  fans  to  cool  the  chip.  In  the  case  of  the  wearable  this  problem  is  very  serious 
since  fans  cause  the  size  to  grow  and  use  battery  power.  As  processor  speeds  and  therefore 
temperature  increase  it  will  be  critical  that  we  reach  a  solution  to  this  problem.  A  recent 
demonstration  by  Fujitsu  Electronics,  showed  a  fan  with  a  tube  that  moves  the  heat  out  of  the 
case,  dropping  temperatures  by  at  least  one-third. 


Although  the  wearable  shown  in  Figure  5  is  ergonomically  a  good  solution,  the  user  would 
like  an  even  smaller  lighter  wearable  PC.  In  addition  to  following  the  technical  advances  of 
wearable  computer  manufacturers,  we  are  watching  closely  the  downsizing  of  laptop  computers 
and  the  upsizing  of  Windows  CE  devices.  It  is  our  vision  that  all  PC  vendors  are  converging  on  a 
wearable  PC  that  can  be  carried/worn  unobtrusively  and  that  will  provide  connectivity  to  the 
Internet.  The  wearable  PC  will  be  a  part  of  our  everyday  lives,  providing  us  with  information 
and  communications  services. 


B.  Battery  Technology 

While  great  strides  have  been  made  to  reduce  the  size  and  weight  of  batteries,  most 
wearable  applications  require  an  eight  hour  “run  time,”  i.e.,  constant  availability  throughout  the 
workday.  While  a  user  will  accept  charging  the  battery  each  day,  the  user  will  not  accept 
gracefully  “shutting  down”  the  wearable  to  put  in  a  new  battery  during  their  workday.  Batteries 
must  continue  to  shrink  in  size  and  weight,  while  allowing  additional  run  time. 

We  have  tested  Nickel  Metal  Hydride  (NiMH),  Lithium  Ion  (Li-on)  and  Nickel 
Cadmium  (NiCd)  batteries  along  with  power  management  software.  While  our  goal  has  been  an 
eight-hour  battery  life,  the  dramatic  increase  in  CPU  speeds  and  the  power  consumption  of  a 
color  display  have  prevented  us  from  meeting  our  goal.  We  had  great  hopes  for  greatly  increasing 
battery  life  when  we  heard  about  Intel’s  “Tillamook”  mobile  CPU,  which  had  a  greatly  reduced 
power  requirement  (from  3.4  to  1.8  volts).  Unfortunately,  the  chip’s  increased  processing  speed 
negated  most  of  the  power  saving,  providing  us  with  only  a  30-minute  increase  in  battery  life. 
We  are  told  by  battery  manufacturers  that  new  technology,  which  will  be  in  the  market  in  the 
next  three  to  five  years,  will  solve  our  problems,  but  for  now  the  user  must  “wear”  two  batteries 
to  attain  the  desired  eight-hour  operation  time. 


C.  Voice  Recognition 

Microphones  are  a  key  component  for  proper  voice  recognition.  Open  boom  mikes 
typically  pick  up  too  much  noise  for  acceptable  voice  recognition.  Head-mount,  “close-talk” 
microphones,  especially  those  enhanced  with  active  noise  canceling  circuitry,  have  been  highly 
successful  in  a  typical  laboratory  or  office  environment.  However,  there  are  problems  with  voice 
recognition  in  high  noise  environments  with  these  types  of  microphones.  It  is  also  important  to 
note  that  the  variety  of  commercially  available  speech  engines  will  perform  differently  in  high 
noise  environments.  Earpiece  microphones  use  a  unique  device  that  incorporates  a  microphone 
and  speaker  in  a  molded  form  to  fit  into  the  ear  similarly  to  a  hearing  aid  device.  The  ear 
microphone  senses  vibration  of  the  ear  bone  when  the  user  speaks,  and  the  molded  earpiece 
provides  an  excellent  means  of  blocking  external  high  level  noise.  We  are  also  evaluating  throat 
microphones,  which  wrap  around  the  throat  to  pickup  vibration,  and  skull  microphones,  which 
rest  on  top  of  the  user’s  head  usually  as  part  of  a  helmet  assembly. 


Voice  recognition  technology  will  need  to  improve  both  in  its  ability  to  recognize  an 
extensive  vocabulary  and  to  recognize  words  spoken  by  a  wide  range  of  individuals.  The  ability 
to  use  our  voice  in  place  of  the  keyboard  and/or  mouse  is  most  critical  in  that  the  wearables  will 
not  be  a  “hands  free”  device  until  voice  recognition  becomes  second  nature  to  the  user. 


Specifically,  we  are  looking  for  a  low  cost  speaker  independent  Windows 
NT/Intemet  Browser  compatible  voice  recognition  engine  which  offers  high  (>90%)  recognition 
in  high  ambient  noise  environments.  We  have  performed  extensive  testing  and  research  in  the  area 
of  voice  recognition.  Voice  recognition  products  from  Texas  Instruments,  IBM,  Microsoft, 
Verbex  and  Dragon  Systems  have  been  evaluated.  While  voice  recognition  software  and  noise 
canceling  microphones  have  improved,  the  greatest  jump  was  made  with  the  introduction  of  the 
Pentium.  With  a  133MHz.  Pentium  and  above,  we  have  achieved  a  voice  recognition  capability 
of  98  percent  in  low  ambient  noise  environments.  We  are  now  searching  for  a  solution  to 
achieving  a  high  rate  of  recognition  in  high  ambient  noise  situations,  such  as  the  flight  line  or  in  a 
hangar. 


D.  Optical  System 

Improvements  to  optical  functionality  and  comfort  are  needed.  In  the  best  of 
today’s  systems,  the  optical  system  is  “in  the  way”  of  the  user.  It  either  hangs  in  front  of  the 
user  or  is  wrapped  around  their  head  making  the  wearable  uncomfortable  when  worn  for  more 
than  a  short  period  of  time.  Optical  information  will  need  to  be  made  available  in  an  unobtrusive 
display  that  will  be  comfortable  to  the  user,  while  displaying  high  definition  information. 
Specifically,  we  are  looking  for  a  SVGA/PC  compatible  display  that  can  be  head  or  body 
mounted,  adjustable  for  eye  dominance  and  focus. 

A  Head  Mounted  Display  (HMD)  of  particular  interest  was  exhibited  at  the 
International  Symposium  on  Wearable  Computers,  held  during  October,  1997.  The  HMD 
designed  by  MicroOptical  Corporation,  shown  in  figure  6,  appear  to  be  a  normal  set  of 
eyeglasses.  In  fact,  what  MicroOptical  has  developed  with  funding  from  DARPA  and  the  Army 
is  a  normal  set  of  eyeglasses  that  include  a  concealed  electronic  display.  When  the  user  wears  the 
glasses  and  turns  the  display  on,  an  image  of  a  video  or  computer  screen  appears  at  a  distance  of 
several  feet.  A  focus  adjustment  allows  the  user  to  place  the  image  at  a  comfortable  distance. 

The  eyeglasses  perform  the  same  functions  as  ordinary  corrective  lenses,  sunglasses, 
or  safety  glasses.  Additionally,  the  glasses  provide  the  user  with  a  convenient,  portable  means  for 
carrying  a  display  that  may  be  connected  to  a  wearable  computer  or  other  electronic  device.  Such 
eyeglasses  are  expected  to  become  increasingly  important  as  wearable  electronic  products  enter 
the  market. 

A  computer,  VCR,  television,  or  other  electronic  device  generates  a  signal  that  carries 
the  image  electronically  up  to  the  eyeglass  frame.  A  small  liquid  crystal  display  is  used  to 


generate  the  image  that  the  user  sees.  The  light  rays  from  the  liquid  crystal  display  are  relayed  to 
the  eye  through  reflectors  within  the  eyeglass  lens.  The  reflectors  fold  the  optical  path  and 
magnify  the  image  so  that  it  can  be  viewed  comfortably.  The  user  perceives  an  image  floating  in 
space  at  an  adjustable  focal  distance  of  three  feet  or  more. 

When  the  display  is  turned  off,  the  computer  image  disappears  and  the  glasses  revert 
to  ordinary  glasses.  The  user  can  see  through  the  eyeglass  lens. 


The  technology  includes  prescriptive  correction.  MicroOptical  has  demonstrated 
eyeglasses  with  an  approximate  correction  of  -5  diopters,  and  most  prescriptions  should  work 
well. 

The  image  presently  provides  320  by  240  pixels  with  8-bit  grayscale.  The  field  of 
view  is  approximately  8  degrees  (horizontal).  A  color  display  has  also  been  demonstrated.  While 
stereo  glasses  are  not  currently  being  developed,  the  technology  can  be  applied  to  both  lenses  in 
the  eyeglasses  to  form  a  3D  image. 

The  eyeglass  lens  is  unique  in  the  manner  that  the  computer  image  is  brought  to  the 
eye.  Specifically,  there  are  no  external  lenses  or  other  optical  components  so  that  the  eyeglass 
lens  can  be  inserted  into  an  eyeglass  frame  having  ordinary  appearance.  The  electronic  circuits  are 
built  into  the  temple  of  the  glasses.  While  the  electronics  are  currently  contained  in  a  very  small 
pod  on  the  side  of  the  glasses,  MicroOptical  intends  to  conceal  all  of  the  electronics  and  optics  in 
the  eyeglass  frame. 


Figure  6 

MicroOptical  Eyeglass  Display  System 


E.  Wireless  Communication 

It  is  a  certainty  that  high  bandwidth  wireless  connectivity  to  the  Internet  must  be 
attained  in  the  development  of  a  hands  free  computing  environment.  While  many  of  us  are  quite 
familiar  with  analog  or  digital  cell  phones  and  some  of  us  even  exchange  data  using  Cellular  Digital 
Packet  Data  (CDPD)  through  your  local  carrier,  its  maximum  rate  of  19.2Kbps  will  not  fulfill  our 
mission  requirements. 


The  mission  requirement  to  send  and  receive  voice,  data,  graphics  and  video  to  the 
Internet  generates  a  minimum  need  for  a  rate  in  Mbps  or  a  T-l  rate  (1.55Mbps)  and  beyond. 
This  requirement  is  not  impossible  to  meet,  but  unlike  the  simplicity/low  cost  of  CDPD,  reaching 
T-l  rates  and  beyond  is  met  with  technical  roadblocks  and/or  can  be  quite  costly. 

In  meeting  our  requirement  we  first  considered  infrared  (IR) .  While  the  original  IR 
standard  permitted  a  maximum  of  115.2Kbps,  the  Infrared  Data  Association  (IrDa)  has  recently 
approved  version  1.1,  nicknamed  Fast  IR.  Fast  IR  will  transmit  information  up  to  4Mbps.  The 
big  drawback  is  the  fact  that  IR  needs  line  of  sight  and  while  this  requirement  can  be  met  in  an 
controlled  environment  such  as  an  office,  and  while  hubs/repeaters  could  used,  connectivity 
would  be  very  difficult  to  achieve  in  the  world  of  avionics. 

We  next  considered  Radio  Frequency  transmission  methods.  Unlike  IR,  even  a  low 
power  lOOmw  signal  can  reach  120  feet  indoor  and  several  hundred  feet  outside.  To  overcome 
“shadowing”  when  the  user  steps  inside  the  aircraft  or  the  aircraft  is  between  the  user  and  the 
server  we  found  suitable  locations  to  “hang”  repeaters  on  both  sides  of  an  aircraft.  In  testing  we 
found  that  highest  rate  that  we  achieved  with  a  T-l  rated  PCMCIA  card  in  a  wearable  was 
600Kbps,  while  this  was  a  great  improvement  over  cellular  packets,  we  were  disappointed  in  its 
inability  to  reach  true  T-l  speeds.  While  we  could  send  and  receive  graphics  and  streaming  video, 
the  need  for  greater  bandwidth  was  apparent  when  more  than  one  client  requested  video  streams 
from  the  server.  We  then  tried  a  similar  wireless  LAN  solution  with  PCMCIA  cards  that  were 
rated  at  lOMBps.  While  this  configuration  showed  great  improvement,  we  found  that  when 
multiple  users  attempted  to  link  back  to  the  server,  performance  was  not  at  an  acceptable  level. 
We  decided  to  pursue  this  solution  we  would  need  to  work  with  industry  to  develop  a  PCMCIA 
card  with  a  low  power  transmitter  that  would  have  a  bandwidth  greater  than  10Mbps. 

The  final  consideration  was  that  of  Satellite  Transmission.  While  military  satellites 
do  exist  and  information  can  be  sent  at  Asynchronous  Transfer  Mode  (ATM)  speed  (155Mbps) 
and  beyond,  we  found  that  availability  and  cost  issues  caused  us  to  put  this  solution  off  until 
availability  and  costs  become  realistic  in  terms  of  our  requirements.  We  decided  to  determine 
what  other  satellite  platforms  were  available.  Motorola  has  a  project  named  “Iridium”  that  calls 
for  the  launch  of  66  low  earth  orbit  satellites  in  the  fall  of  1998.  We  were  disappointed  to  find 
that  the  bandwidth  was  only  2.4Kbps.  Other  low  earth  orbit  satellite  projects,  such  as  Teledesic, 
are  only  a  few  years  away  and  these  projects  will  provide  a  higher  bandwidth  wireless  Internet 
solution. 

Based  on  our  Wireless  research  we  believe  the  best  solution  at  this  time  is  a 
Wireless/RF  LAN  utilizing  PCMCIA  cards  in  our  wearable  PC’s  (Figure  7)  with  access 
points/hubs  (Figure  8)  to  extend  the  range  from  the  aircraft  to  the  server  in  the  hangar.  We  are 
currently  the  technical  point  of  contact  for  an  SBIR  to  research  and  potentially  develop  a  low 
power  RF  PCMCIA  card.  Specific  technical  requirements  include  a  bandwidth  greater  than 
10Mbps  with  encryption  and  LPI  (low  probability  of  Intercept)  over  ranges  approaching  2800 
feet. 


Figure  7  Figure  8 

Proxim  RangeLan2  Proxim  Outdoor  AP  Enclosure 

The  recently  approved  IEEE  802.11  specification  which  was  meant  to  provide 
interoperability  for  Wireless  LAN’s,  will  certainly  be  a  springboard  to  Vendors  such  as  Lucent, 
Proxim,  and  Aironet  to  develop  Wireless  COTS  hardware  that  will  meet  our  bandwidth 
requirements.  Unfortunately,  Lucent  and  Aironet  are  promoting  the  802.11  compliant  Direct 
Spread  Spectrum  (DSSS)  technology,  which  will  attain  10  to  11Mbps.  However,  Proxim,  is 
following  the  European  HiperLAN  specification,  which  can  provide  up  to  23Mbps  throughput 
and  international  usability.  Although,  the  23Mbps-bandwidth  figure  is  inviting,  will  the 
HiperLAN  specification  be  adopted  in  the  United  States  or  will  DSSS  technology  prove  to  be 
the  standard. 


F.  Wearable  Color  Video  Camera 

A  key  portion  of  the  wearable  concept  is  the  ability  to  receive  expert  help  through 
the  Internet.  Specifically  the  user  would  have  a  microphone  and  micro  video  camera  to 
communicate/show  the  avionics  problem  that  needs  expert  help/attention.  We  are  currently 
researching  camera’s  that  will  provide  suitable  wireless  LAN  integration  with  full  duplex  audio 
(voice)  to  provide  a  Tele-video/conference  capability.  We  have  been  very  successful  in  utilizing 
inexpensive  (under  $200)  camera’s  to  send  video  over  a  wireless  network.  However,  when  an 
additional  task  or  when  an  additional  user  utilizes  the  same  wireless  network,  it  is  clear  that 
additional  bandwidth  is  required.  In  addition,  we  must  coordinate  the  usage  of  the  sound  card 
between  the  video  teleconferencing  and  the  voice  recognition  engine  so  that  the  system  continues 
to  be  hands-free  during  the  teleconferencing.  We  are  not  aware  of  any  combination  of  speech 
engine  and  teleconferencing  software  that  presently  provides  this  functionality. 


G.  Extreme  Temperature  Environments 

Navy  Aircraft  are  stationed  throughout  the  world  and  face  a  wide  range  of  severe 
environmental  conditions.  The  wearable  would  be  required  to  operate  below  zero  degrees 
Centigrade  to  +50  degrees  Centigrade.  To  meet  the  Navy’s  mission,  wearable  electronics  will 
need  to  operate  in  these  extreme  conditions  without  failures  dues  to  overheating  or  an  inability  to 


perform  in  conditions  below  freezing.  At  this  point  no  wearable  on  the  market  today  meets  these 
requirements.  In  speaking  with  wearable  manufacturers,  they  believe  external  devices  to  heat  or 
cool  the  wearable  would  be  the  most  cost-effective  method  to  meet  our  requirements. 


VI.  Demonstration  Programs 
A.  Phase  I 

We  have  utilized  the  Quest  Multimedia  Toolkit,  from  Allen  Communications,  to 
develop  a  sample  electronic  MRC  application.  The  Quest  toolkit  allows  for  rapid  drag  and  drop 
development  of  interactive  multimedia  based  applications  without  the  need  for  advanced 
programming  skills. 

We  then  utilized  the  Microsoft  Speech  Application  Programming  Interface  (SAPI)  to 
develop  a  custom  program  utilizing  the  C++  language  to  allow  for  voice  control  of  the  electronic 
MRC.  The  Phase  I  demonstration  proved  the  feasibility  of  a  speaker  independent  voice 
controlled  electronic  MRC  with  built-in  recording  of  pass/fail  statistics  and  tracking  of  tasks  that 
were  not  performed  by  the  AMT.  Figure  9  shows  an  example  of  an  electronic  MRC.  The 
demonstration  was  basically  a  standalone  application,  not  developed  to  be  incorporated  in  a 
client-server-networking  environment. 
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B.  Phase  II 

Our  Phase  II  demonstration,  presently  under  development,  is  being  designed  for 
Internet  and  client-server  compatibility.  Specifically,  we  are  utilizing  Active  Server  Pages,  with 
Visual  Basic  scripting,  to  build  web  pages  that  properly  display  MRC  information  that  is  stored 
in  an  MS  Access  database. 

The  Microsoft  Internet  Explorer,  with  embedded  Active  X  voice  recognition 
software,  will  be  used  to  display  the  electronic  MRC  web  pages. 

The  wearable  PC  user  will  utilize  an  Internet  browser  to  request  information  from  a 
server  in  the  same  way  we  surf  the  web,  with  the  enhancement  of  voice  control. 


VII.  The  Future 

We  are  extremely  excited  about  the  future  of  wearables  within  the  DoD,  corporations  and 
in  our  private  lives.  It  is  a  certainty  that  wearable  PC’s  will  continue  to  shrink  in  size  and 
weight,  and  they  will  also  drop  in  price  as  chip  prices  decrease  and  as  the  wearable  market 


increases.  The  Seiko  Corporation  has  just  introduced  a  watch  in  Japan  that  is  being  marketed  as 
the  first  wearable  PC.  While  one  could  argue  this  point,  since  it  has  limited  abilities  compared  to 
the  Mentis,  Xybernaut  and  Via  wearables  that  have  been  on  the  market  the  past  two  years,  it  is 
the  first  wearable  PC  marketed  to  the  general  public. 

As  we  discussed  above,  there  are  many  challenges  ahead  of  us,  however  we  believe  the 
wearable  will  meet  DoD’s  needs  regarding  Avionics  Maintenance  and  many  other  areas  where  a 
truly  personal  computer  would  help  to  increase  communications,  accuracy  and  productivity. 
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Abstract  —  As  the  Department  of  Defense  (DOD)  downsizes  there  is  a  great  need  to  reduce  the  cost 
and  manpower  burden  associated  with  maintenance  of  weapon  systems.  Traditionally,  technical 
manuals  used  for  field  maintenance  of  DOD  systems  have  relied  heavily  on  troubleshooting 
procedures,  which  are  presented  in  "flow  chart "  format  of  fault  trees.  These  flow  charts  guide  the 
maintainer  through  test  procedures  to  isolate  parts  that  cause  equipment  malfunction.  These 
procedures  are  static,  that  is,  they  are  highly  structured  around  a  predetermined  sequence  of  tests,  do 
not  become  "smarter  "  over  time  with  historical  maintenance  data,  and  only  take  into  account  those 
symptoms  and  faults  which  the  original  developer  considered.  They  are  often  incomplete,  sometimes 
wrong,  and  are  very  difficult  to  update  and  maintain.  As  maintenance  evolved  into  the  computer- 
assisted  age,  a  major  opportunity  exists  to  significantly  enhance  the  technical  manuals,  the  basic 
logic,  and  information/knowledge  representation  underlying  troubleshooting  procedures..  This  paper 
provides  the  high  lights  of  research  and  development  results  on  the  technical  aspects  as  how  to 
efficiently  transition  from  flow-chart  intensive  knowledge  representation  to  a  knowledge-based 
system.  The  results  of  reengineering  the  legacy  trouble-shooting  procedures  provides,  at  least,  the 
following  benefits:  (1)  replacing  fault  trees  with  knowledge  based  reasoning  about  faults  related  to 
symptoms;  (2)  providing  the  capability  to  dynamically  relate  faults  to  symptoms;  (3)  equipping  the 
ability  to  use  historical  maintenance  data  to  continuously  improve  maintenance  capability;  (4) 
providing  more  user-friendly  interactive  electronic  technical  manuals;  and  (5)  providing  the  ability 
to  house  "expert"  diagnostics  information  in  a  form  that  becomes  usable  and  available  to  novice 
technicians. 


I.  INTRODUCTION 

Currently,  field  maintenance  of  Department  of  Defense  (DOD)  weapon  systems  relies  heavily  on 
troubleshooting  procedures  (TPs).  However,  these  TPs  are  in  a  "flow  chart"  format  of  fault 
trees.  The  TPs  are  static,  that  is,  they  are  highly  structured  around  a  predetermined  sequence  of 
tests  and  they  do  not  grow  smarter  over  time  with  the  use  of  maintenance  historical  data. 
Moreover,  the  TPs  are  sometimes  incomplete  and/or  inaccurate  in  performing  diagnostics.  The 
TPs  are  also  cumbersome  and  poorly  integrated  with  embedded  test  and  automated  test 
procedures.  These  factors  result  in  a  significant  maintenance  burden  for  the  DOD. 

To  cope  with  the  DOD’s  shrinking  budget  and  downsizing,  reengineering  TPs  to  reduce  this 
maintenance  burden  is  a  must. 

The  Advanced  Technology  Office  (ATO),  U.S.  Army  Test,  Measurement,  Diagnostic 
Equipment  Activity  (USATA),  U.S.  Army  Aviation  and  Missile  Command,  initiated  a  research 
and  development  (R&D)  effort  to  reengineer  the  TPs  in  1995.  In  December  1996,  the  ATO 


teamed  up  with  the  Logistics  Support  Engineering  Directorate,  ARDEC  and  Giordano 
Automation  Corporation  (GAC)  to  investigate  and  develop  an  enhancement  methodology  for 
reengineering  the  technical  manual's  TPs.  This  paper  provides  some  of  the  key  results  of  our 
efforts. 

n.  ISSUES  WITH  TPs  AND  TECHNICAL  MANUALS  (TMs) 

In  general,  the  TPs  contained  within  TMs  have  following  issues  that  make  them  noneffective  and 
result  in  a  big  maintenance  burden: 

A.  Most  troubleshooting  logic  is  represented  in  flow-chart  format  of  "Fault  Tree".  The 
troubleshooting  logic  flows  as  follows:  The  results  of  one  test  leads  to  execution  of  the  next  test, 
whose  result  in  turn,  leads  again  to  the  next  test.  In  short,  the  sequence  of  tests  are 
predetermined  and  inflexible. 

B.  Fault  trees  are  developed  as  part  of  the  TM  development  process  and  are  based  upon  a 
specified  set  of  fault  conditions.  They  are  static,  that  is,  they  do  not  adapt  to  new  or  unplanned 
fault  modes  and  they  do  not  improve  over  time,  based  upon  field  experience. 

C.  Fault  trees’  static  logic  is  limited  to  a  "single  fault  assumption"  and  in  multiple  fault 
situations,  can  become  very  unreliable.  This  results  in  incomplete  and/or  inaccurate  in  diagnosing. 

D.  The  TPs  and  TMs  are  often  very  cumbersome  and  poorly  integrated  with  embedded  test  and 
automated  test  procedures.  This  results  in  ineffective  maintenance  or  no  maintenance  solution. 

III.  ENHANCEMENT  GOAL 

The  goal  of  this  R&D  efforts  is  to  significantly  improve  the  TPs  and  TMs  to  reduce  mean-time- 
to  repair,  maintenance  training  requirements,  and  maintenance  costs.  For  field  diagnostics,  the 
goal  is  to  reengineer  static  TPs  into  a  much  more  robust,  simpler,  and  dynamic  fault  isolation 
mechanism.  For  the  TMs,  integration  with  embedded  test  and  automated  test  procedures  must 
be  enhanced  be  more  interactive  and  user-friendly. 

IV.  TECHNICAL  APPROACHES 

To  accomplish  the  goal,  a  new  paradigm  of  diagnostics  reasoning  technology  is  required  that  has 
the  capability  to  eliminate  complex  diagnostic  logic  paths  and  the  capability  of  receiving  and 
dynamically  interpreting  any  test  results  from  any  source,  in  any  order,  and  with  as  many  or  as 
few  test  results  at  a  time  [2, 3, 4, 5].  Moreover,  an  Interactive  Electronic  Technical  Manual 
(IETM)  authoring  and  display  system  must  be  robust  and  be  able  to  integrate  the  diagnostics 
logic,  the  test  procedures  and  routines,  and  technical  manual  information  to  provide  a  truly 
interactive  interface  between  users,  systems,  test  resources,  and  maintenance  functions  [6]. 


For  these  purposes,  the  technical  approach  requires,  firstly,  a  diagnostics  mechanism  wherein 

diagnostics  logic  is  an  entity  independent  of  test  procedures  and  routines,  that  is  able  to 
dynamically  interpret  test  results,  and  whose  diagnostics  logic  can  be  recaptured  from 
legacy  TPs  and  other  data  from  TMs. 

Secondly,  it  requires  an  overall  object-oriented  structure  and  an  open  architecture.  The 

concept  of  object-oriented  programs  enable  taking  full  advantage  of  dealing  with  the  diagnostic 
logic  as  an  entity  independent  of  test  procedures  and  routines.  The  independent  diagnostic  logic 
contained  in  the  software  object  can  be  rehosted  to  any  platform  without  any  problem,  because  it 
is  simply  a  software  object  -  such  as  a  binary  file  [4,5]. 

Thirdly,  it  also  requires  an  IETM  authoring  and  display  package,  which  is  CALS-compliant  and 
also  highly  robust.  This  authoring  system  must  be  able  to  integrate  the  diagnostics  logic,  the  test 
procedures  and  routines,  technical  manual  information,  and  other  required  maintenance 
information  to  provide  truly  interactive  and  full  complement  of  dialogs. 

In  looking  for  a  new  paradigm  of  diagnostics  technology  satisfying  above  requirements, 
Diagnostician  was  identified.  The  Diagnostician  is  a  greatly  enhanced  model-based  diagnostic 
reasoning  system  that  is  significantly  enhanced  from  DARTS,  a  concept/technology  developed 
by  the  ATO,  USATA,  and  GAC  during  1992-1993  [1]  and  commercialized  by  the  GAC.  The 
Diagnostician’s  model-based  diagnostic  software  is  used  in  an  object-oriented  software 
environment  -  the  diagnostics  logic  is  an  independent  entity  that  is  able  to  dynamically  interpret 
test  results.  The  basic  knowledge  used  by  the  Diagnostician  includes  a  fault  propagation  model 
that  maps  all  possible  faults  to  all  possible  symptoms  (tests  or  visual  observations).  Normally, 
the  basis  for  this  mapping  is  derived  (automatically  translated)  from  computer  aided  design 
(CAD)  data  (netlists  describing,  hierarchy,  interconnectivity,  components  and  pins,  and  signal 
flow). 


The  Diagnostician’s  knowledge  bases,  called  a  fault/symptom  matrix,  is  a  model  in  the  form  of  a 
connectivity  matrix  that  represents  the  propagation  of  faults  (rows  in  the  matrix)  to  observable 
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measurement  locations  and  the  coverage  of  tests  that  Pass  or  Fail  (columns  in  the  matrix) .  (See 
Figure  1).  When  used  in  run-time,  the  Diagnostician’s  algorithms  and  knowledge  bases  (matrix) 
operate  to  isolate  fault  without  troubleshooting  sequences  and  without  hard-code  diagnostic  logic. 

To  identify  the  required  IETM  authoring  system,  a  study  was  conducted  by  the  ATO  over  four 
authoring  systems.  A  chapter  of  a  paper  technical  manual  was  selected  and  converted  into  an 
IETM  using  each  authoring  tool.  This  was  done  to  evaluate  the  features  of  each  tool  [6] .  Sixteen 
different  features  of  these  authoring  tools  were  investigated.  These  features  include  spell 
checking,  animation,  audio,  video,  execution  of  external  programs,  implementation  of  hotkeys  for 
voice  actuation,  ease  of  linking  frames,  hotlinks  capabilities,  flexibility,  whether  or  not  a 
standardized  format  is  required,  whether  the  authored  text  requires  compilation  before  viewing, 
graphics  requirements,  Object  Linking  and  Embedding,  cost,  provisions  for  DCA,  J1708,  J4  and 
1553  connections  and  interfacing  and  the  troubleshooting  capabilities  of  the  IETMs. 

The  Raytheon  (formerly  Hughes)  “Advanced  Integrated  Maintenance  Support  System 
(AIMSS)  ”  IETM  authoring  and  display  system  was  identified  to  be  the  best  IETM  authoring 
system  for  this  development  effort.  The  AIMSS  is  a  CALS-compliant  and  Class  IV  SGML 
IETM  system.  The  AIMSS  uses  overall  object-oriented  structure  and  is  an  open  architecture 
approach.  It  can  integrate  the  overall  IETM  with  diagnostics  logic,  test  procedures  and  routines, 
technical  manual  information,  and  other  requirements.  AIMSS  uses  a  common  graphical  user 
interface  to  display  maintenance  information  in  text,  graphics,  and  table  windows  that  can  be 
easily  manipulated  by  the  technician  for  preferred  viewing.  Hypertext  and  graphic  "hot  spots" 
are  embedded  in  descriptions  and  procedures  to  provide  rapid  access  to  related  information 
contained  in  the  database. 


V.  REENGINEERING  PROCESS 


The  objective  of  the  R&D  efforts  is  to  identify/develop  a  methodology/process  to  significantly 
improve  the  TPs  and  TMs  to  reduce  mean-time-to  repair,  maintenance  training  requirements,  and 
to  reduce  maintenance  costs.  As  mentioned  above,  the  Diagnostician  will  enhance  legacy  TPs 
by  using  dynamics  model-based  reasoning.  Normally,  the  Diagnostician’s  diagnostics 
knowledge  bases  are  derived  from  the  systems’  design  information.  For  legacy  systems,  the 
paper  TMs  and  their  TPs  are  the  primary  source  of  information  that  pertains  to  diagnostics.  The 
issue  now  is  how  to  cost-effectivelv  reengineer  the  TPs  into  dynamic  knowledge  bases  for  use 
with  the  Diagnostician.  The  solution  is  to  implement  the  following  three  steps  cost  effectively: 
(1)  Capture  Diagnostics  Logic  from  Paper  TMs:  (2)  Reengineer  Test  Ordering 
Constraints  and  Information:  and  (3)  Seemlesslv  Integrate  Experiences  into  Model  Based 
Diagnoses. 

A.  Capture  Diagnostics  Logic  from  Paper  TMs 

Normally,  and  optimally,  the  diagnostic  knowledge  base  is  automatically  generated  from  CAD 
output  files,  or  netlists.  A  primary  benefit  of  Diagnostician  is  its  model-based  diagnostics 
approach— a  design-derived  knowledge  base  that  is  a  one-for-one  representation  of  the  design. 
That  is,  the  direct  relationship  between  design  and  fault  propagation.  For  legacy  TMs,  this  does 
not  exist  and  even  the  netlist  data  may  not  exist.  Therefore,  alternate  means  for  data  import  are 
required  to  reconstruct  the  relationships  between  symptoms  and  faults.  In  reengineering  TMs’ 
TPs,  the  best  we  can  hope  to  accomplish,  initially,  is  to  generate  a  diagnostic  representation  that 
is  as  good  as  the  existing  TPs,  because  data  is  limited  and  we  must  assume  that  further 
information  is  unavailable.  Note  that  a  fault  tree  is  an  interpretation,  and  the  reengineering  of  that 
fault  tree  into  a  knowledge  base  is  a  further  interpretation  of  that  interpretation. 

There  are  four  alternatives  to  capture  legacy  diagnostic  data.  The  users  can  use  any  one  or  more 
to  cost-effectively  capture  the  diagnostic  data. 

1.  Capture  SGML  Tagged  Data  -  Automated  software  routines  were  written  to  extract 
diagnostic  logic  from  SGML  tagged  data.  The  Army's  2361  DTD  was  analyzed  with  respect  to 
data  content  of  troubleshooting  logic.  A  standard  format  was  developed  that  allows  conversion 
tools  to  be  tailorable  to  other  DTDs,  since  the  basic  content  is  expected  to  be  the  same. 

2.  Capture  From  Paper-Based  Troubleshooting  Trees  -  A  reengineering  methodology  and 
supporting  tools  have  been  developed  to  analyze  the  fault  tree  structure  representation  of  TPs 
and  represent  that  tree  structure  in  a  knowledge  base  format.  The  reengineering  methodology 
includes  generating  the  diagnostic  model,  defining  each  test  procedure,  and  incorporating  the  test 
path  to  each  fault  using  the  tools  inside  the  Diagnostic  Profiler. 

3.  Capture  from  an  "Expert"  -  If  an  engineer  or  technician  having  expertise  on  the  system 
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application  is  available,  that  expert  can  create  the  diagnostic  model  by  directly  authoring  the  fault 
conditions  and  correlating  the  test  results  or  symptoms  to  those  fault  conditions  (define  how 
tests  "cover"  faults). 

4.  Capture  from  Schematic  Data  -  If  detailed  schematic  data  is  available,  as  well  as 
knowledge  on  test  coverage,  the  user  can  use  a  schematic  capture  program,  such  as  OrCAD,  to 
enter  schematics  and  output  EDIF  netlist  files.  These  files  can  be  directly  imported  to  the 
Diagnostic  Profiler. 

B.  Reengineer  Test  Ordering  Constraints  and  Information 

In  most  TPs,  test  sequences  are  predetermined  by  fault  tree  structures.  The  tree  structures 
represent  the  results  of  an  analysis  rather  than  the  underlying  information  from  which  they  were 
generated. 

During  the  R&D  efforts,  it  was  determined  that  additional  test  ordering  services  must  be  added  to 
the  Diagnostician  to  make  it  truly  serviceable  for  reengineering  legacy  TMs’  TPs.  Two  factors 
that  provide  overriding  test  order  constraints  are  (1)  the  impossibility  of  implementing  tests 
under  certain  circumstances  (e.g.,  measuring  a  frequency  on  a  signal  with  no  amplitude  or 
checking  a  powerless  display  for  fault  codes),  and  (2)  the  need  to  use  tests  to  step  a  unit  under 
test  through  each  of  its  states  (e.g.,  power  up,  set  mode,  start  function,  handle  error,  etc.) 
especially  when  stepping  from  one  state  to  another  takes  a  relatively  long  time. 

Based  on  these  findings,  a  set  of  conditions  and  associated  constraints  or  actions  was  developed 
to  be  used  in  generating  tests  dynamically.  Each  test  could  have  no  conditions  placed  on  it, 
conditions  about  the  status  of  one  or  more  tests  placed  on  it,  or  conditions  about  the  status  of  all 
the  other  tests  placed  on  it.  Test  conditions  and  constraints  include  whether  the  test  is  permitted 
to  be  run,  whether  it  is  prohibited  from  being  run  and  whether  it  is  forced  to  be  run  based  upon 
the  outcome  of  previously  run  tests. 

C.  Seemlessly  Integrate  Experience  Data  into  the  Model  Based  Diagnostics 

Now,  the  legacy  TPs  have  been  reengineered  into  model  based  diagnostic  logic,  inferences  are 
structured  in  an  object-oriented,  database-type  software  architecture,  and  the  underlying  data  can 
be  easily  improved  and  updated  over  time.  With  these  enhancements,  run-time  diagnostics  can  be 
"smartened"  by  incorporating  field  information  into  appropriated  diagnostic  reasoning.  There  are 
many  useful  data  sources  and  situations  that  can  smarten  diagnoses:  Frequency  of  Parts’ 
Failures;  Failure  Modes;  New  or  Unforeseen/Un-Modeled  Failure  Modes;  New  or  Unforeseen/ 
Un-ProfUed  Test  Data;  and  Mismatches  in  Diagnostic  Knowledge  Base  (DKB)  based  on 
Incorrect  Design  Data  Modeling  and/or  Test  Coverage  Input,  etc. 

To  make  the  best  use  of  the  historical/field  data  mentioned  above,  the  overall  implementation 
strategy  is  to  collect  data  on  a  local  basis  and  allow  this  local  data  to  be  automatically 
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incorporated  into  the  diagnostic  reasoning  process  for  current/local  diagnostic  sessions.  The 
experience  data,  all  local  history,  would  be  collected  and  processed/coordinated  by  a  central 
facility.  The  historical  data  would  be  analyzed  with  automated  tools  and  the  system  DKB  would 
be  updated  accordingly.  Then,  processed/coordinated  data  will  be  redistributed  to  each  using  site. 

The  refinement  and  maturation  of  the  DKB  can  be  performed  as  follows: 

1.  Frequency  of  Parts’  Failures  and  Failure  Modes  (Failure  Probability  Updates)  -  The 

DKB  contains  relative  failure  rate  information  that  is  used  to  determine  the  most  probable  cause 
of  a  set  of  symptoms.  For  diagnostic  sessions  where  there  is  an  ambiguity  group,  failure 
probability  data  is  used  to  weigh  the  most  probable  suspect. 

A  "Run-time  Smartener  (RTS)"  has  been  developed  to  incorporate  failure  rate  data  from  actual 
field  experience.  The  RTS  utilizes  the  original  failure  rate  data  as  initial  Bayesian  probabilities  and 
updates  these  probabilities  from  a  log  file  each  time  that  a  repair  has  been  identified  to  correct  a 
problem.  User  input  has  been  minimized. 

To  implement  the  RTS,  a  Fault  History  Database  is  extracted  from  the  historical  maintenance 
records/database,  or  directly  from  Diagnostician  data  logging  mechanisms.  At  the  local  level, 
mechanisms  have  been  incorporated  to  the  Diagnostician  to  automatically  update  fault 
probability  data  based  on  the  field  experience  indicated  by  a  Fault  History  Database.  This  is 
accomplished  through  a  secondary  file  containing  updated  probability  data.  Incorporation  of 
these  updates  into  the  primary  DKB  is  performed  at  the  centralized  maintenance  activity.  The 
updated  DKB  is  then  distributed  to  local  users. 

2.  New  or  Unforeseen/Un-modeled  Failure  Modes  -  To  improve  diagnoseability  for  the 
new  or  unforeseen/un-modeled  failure  modes,  an  Observable  History  Database  (OHD)  is  created. 
An  OHD  is  a  database  that  contains  any  faults  that  were  unaccounted  for  by  the  DKB  in  a 
maintenance  session.  It  is  extracted  from  the  historical  maintenance  records/database  as  a 
secondary  file  accessed  by  the  Diagnostician  during  a  diagnostic  session.  The  OHD  would  reflect 
that  fault  mode.  The  symptoms  that  were  observed  or  tests  that  were  measured  will  be  noted  and 
the  knowledge  base  structure  filled  in  accordingly.  The  fault  data  would  be  denoted  as  a  learned 
mode.  Certain  symptom  data  may  need  to  be  noted  as  "masked"  for  uncertain  test  data.  For 
these  learned  modes,  in  some  cases,  it  may  not  be  appropriate  to  use  pass  data  to  eliminate  a 
fault  mode  in  the  reasoning  process,  since  the  confidence  in  the  test  coverage  data  is  more 
uncertain  (not  physically  tied  to  the  model.)  If  this  is  so,  only  fail  test  data  is  used  for  reasoning, 
not  pass.  Some  sort  of  a  confidence  level  should  be  attributable  to  the  learned  fault  mode. 

3.  New  or  Unforeseen/Un-Profiled  Test  Data  (Observables)  -  The  fault/symptom  matrix 
columns  represent  coverage  of  specific  tests’  measurements.  When  new  or  unforeseen/un¬ 
profiled  test  data  occurs,  the  fault/symptom  matrix  columns  will  be  updated  to  reflect 
fault/symptom  matrix,  and  hence,  the  diagnoses.  If  a  test  fails,  the  potential  faults,  which  could 
have  caused  the  test  to  fail,  are  identified  vertically  down  the  column.  If  new  test  data  becomes 


available,  or  observable,  and  can  be  related  to  a  specific  fault  or  set  of  fault  possibilities,  then  a 
secondary  file  can  be  created/updated  which  denotes  a  new  column  in  the  matrix.  The  new 
column  would  be  identified  as  a  learned  or  added  column.  Certainty  levels  should  be  added  to  the 
possible  faults  associated  with  the  learned  columns.  These  certainty  levels  would  be  different 
from  the  fault  probability  data. 

4.  Mismatches  in  DKB  based  on  Incorrect  Design  Data  Modeling  and/or  Test 
Coverage  Input  -  In  some  cases,  historical  data  may  identify  situations  where  the  DKB  is  wrong 
based  upon  design  information  related  to  fault  propagation  flow.  This  would  result  in  wrong 
items  being  indicted  based  upon  test  results.  Either  the  fault  call-out  excludes  items,  which  are 
possibly  faulty  or  includes  items,  which  are  fault-free.  This  would  have  occurred  from  incorrect 
design  input  data,  which  reflected  the  signal  flow  connection  improperly.  The  case  to  be  fixed  in 
this  situation  is  where  an  item,  which  causes  the  fault,  is  not  included  in  the  ambiguity  group. 

VI.  DIAGNOSTICS  DRIVEN  IETM  INTEGRATION 

The  objective  of  using  AIMSS  IETM  authoring  and  display  package  is  to  develop  diagnostics 
driven  IETM.  This  IETM  provides  the  user  with  the  capability  to  display  maintenance 
information  in  text,  graphics,  and  table  windows  that  can  be  easily  manipulated  by  the  technician 
for  preferred  viewing.  Hypertext  and  graphic  "hot  spots"  are  embedded  in  descriptions  and 
procedures  to  provide  rapid  access  to  related  information  contained  in  the  database.  For  example, 
while  viewing  a  fault  isolation  procedure,  the  technician  is  provided  direct  access  to  related 
information  such  as  schematics  and  parts  lists  via  links  that  are  embedded  in  the  text  of  the 
procedure  and  its  associated  graphics.  The  AIMSS,  a  truly  interactive  authoring  system, 
supports  a  full  complement  of  dialogs  and  processes  that  can  be  embedded  in  interactive 
procedures. 

In  the  Windows  environment,  the  Diagnostician  inference  engine  is  a  Dynamic  Link  Library 
(DLL).  It  is  structured  as  a  library  of  functions  that  provide  diagnostic  services  to  a  client 
program.  Using  the  AIMSS  IETM  authoring  tool,  the  Diagnostician’s  DLL  functions  were 
integrated  through  the  Process  Editor  as  "Class  V"  processes.  The  "Class  V"  process  acts  as  a 
"gateway"  to  all  Diagnostician  services.  Each  "Class  V"  process  interacts  with  the  Diagnostician 
using  Templates.  Each  template  defines  a  DLL  function.  Templates  are  easy  to  use,  provide  the 
function  call's  exact  syntax  requirements,  and  simply  require  the  user  to  identify  specific 
variables,  where  applicable. 

The  Diagnostician  contains  about  forty  DLL  functions.  Of  those,  the  primary  ones  that  will  be 
used  for  a  typical  diagnostics  driven  IETM  application  are  as  follows: 

Load  DKB  Load  a  System's  Diagnostic  Knowledge  Base 


AddData 


Input  test  results  to  the  Diagnostician 


GetNextStep  Identify  next  step  to  be  performed  (normally,  a  test  procedure) 

GetSuspectCnt  Identify  the  number  replaceable  items  in  the  current  fault  call-out 
GetSuspectNamesIdentify  the  name(s)  of  the  replaceable  items  in  the  fault  call-out 
LogData  Log  all  session  history  data  into  the  historical  data  base 

EndSession  End  the  current  diagnostic  session. 

With  these  basic  functions,  the  diagnostic  logic  that  is  authored  into  the  IETM  is  one  "WHILE" 
loop.  The  WHILE  loop  processes  as  shown  in  the  graphic  below.  No  matter  how  large  the 
system,  or  how  complex  the  diagnostic  logic,  this  single  WHILE  loop  (see  Figure  2)  is  all  that  is 
needed  to  incorporate  the  diagnostic  processing  with  the  Diagnostician. 

VII.  BENEFITS  OF  REENGINEERING  TROUBLESHOOTING  PROCEDURES 

The  objective  of  this  effort  was  to  reduce  the  maintenance  burden  of  DOD  weapon  systems  by 
reengineering  static  TPs  of  legacy  TMs.  The  objective  was  achieved  with  the  following  benefits: 

A.  Troubleshooting  Procedures  replaced  by  dynamic  and  more  robust 
diagnostics  capability 

Diagnostician  provides  dynamic  diagnostic  reasoning,  instead  of  static  troubleshooting  trees. 
During  a  maintenance  session,  the  test  results  can  be  input  to  the  Diagnostician  in  any  order  (no 
preset  sequence)  and  from  any  source  individually  or  in  combination  (including  operator 
observations,  test  instruments,  data  bus,  data  file,  built-in  test  (BIT),  automatic  test  equipment, 
system  panels  displays,  etc.).  Test  results  can  be  input  as  many  or  as  few  at  a  time  as  the  test 
source (s)  can  provide  (not  restricted  to  one-at-a-time  to  traverse  down  a  fault  tree).  The 
Diagnostician  zeroes-in  on  causes  of  fault(s)  and  never 


leaves  the  technician  hanging  in  the  middle  of  a  tree!  The  Diagnostician  can  identify  multiple 
faults  (diagnostic  trees  follow  single-fault  assumption).  The  Diagnostician  will  only  request  tests 
that  have  diagnostic  significance,  based  upon  snapshot  of  current  fault  possibilities,  and 
therefore,  may  decrease  overall  repair  time  and  increase  diagnostics  accuracy. 

B.  Capability  of  Using  Historical  Maintenance  Data  to  Continuously 
Improve  Diagnostic 

Data  Logging  of  Maintenance  History  was  defined  for  continuous  system  diagnostic  learning. 
The  Diagnostician  creates  a  log  of  session  profiles.  This  log  is  used  by  the  RTS  utility  to  mature 
diagnostic  capability  over  time.  The  RTS  performs  statistical  analysis  on  session  history  data  to 
identify  trends  and  actual  field  failure  rate  data.  This  is  used  to  automatically  or  semi- 
automatically  update  the  DKB  and  provide  improved  diagnostics. 

C.  Built-in  Test  Data  are  used  for  maintenance 

Most  BIT  is  designed  to  support  operations,  not  maintenance,  because  it  focuses  on  fault 
detection  at  the  functional  level  as  opposed  to  diagnostics  at  the  replaceable  item  level.  The 
Diagnostician  can  interpret  any  BIT  data  and  correlate  BIT  results  to  a  component/item-oriented 
model  of  the  system.  It  therefore  extends  BIT  into  a  maintenance  mode  to  enhance  field 
diagnostics  and  maintenance. 

D.  Class  V  Diagnostics  driven  IETMs  vs.  paper  TMs 


A  much  more  user-friendly  IETMs  capability  was  developed,  providing  the  capability  to  house 
"expert"  diagnostics  information  in  a  form  that  becomes  usable  and  available  to  novice 
technicians. 

The  following  are  additional  benefits  for  IETM  developers: 

E.  IETM  Authoring  of  Diagnostics  is  Greatly  Simplified 

Authors  are  not  required  to  author  the  complex  "IF  THEN.. .GOTO"  logic  associated  with 
structured  diagnostic  trees  -  all  diagnostic  logic  is  inside  the  DKB.  The  author  simply  creates  one 
WHILE  loop  to  manage  the  dialog  with  the  Diagnostician. 

F.  Possible  Elimination  of  SGML  tag  the  troubleshooting  logic 

SGML  tagging  for  diagnostics  is  very  complex  and  requires  extensive  content  tagging.  This  can 
be  eliminated  by  creating  the  DKB  from  design  data  or  from  an  engineering  analysis  of  the 
troubleshooting  trees  directly. 

VIII.  CONCLUSION/SUMMARY 

The  R&D  project  to  create  the  capability  of  reengineering  troubleshooting  procedures  into 
dynamic  model-based  diagnostics  was  successfully  completed.  The  new  paradigm  for 
diagnostics,  the  Diagnostician  and  the  AIMSS  IETM  authoring  and  display  package  worked 
together  very  efficiently  to  accomplish  the  reengineering  task.  The  troubleshooting  procedures 
from  TM  for  the  Army’s  Fox  NBC  Reconnaissance  vehicle  was  used  as  a  testbed.  A  diagnostics 
driven  IETM  was  successfully  completed  for  Fox.  The  maintenance  school  is  using  it  as  a 
training  tool.  This  methodology  to  reengineer  troubleshooting  procedures  in  TMs  is  generic  and 
can  be  reused  for  other  legacy  systems  both  from  DOD  and  commercial  industry. 
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Abstract 

This  paper  presents  the  state  of  the  art  in  real  time  reactive  supervision  using  micro-module  sensors. 
The  paper  will  show  how  automatic  test  equipment  is  becoming  more  and  more  an  anachronism  as  the 
Joint  Strike  Fighter  Prognostic  Health  Management  (PHM)  team  forges  new  links  that  connect  on¬ 
board,  event  based  diagnostics  and  prognostics  to  ground-based  support.  The  paper  will  discuss  how 
on-aircraft  PHM  combines  micro  electro-mechanical  systems  (MEMS)  and  micro-electro-optical 
systems  (MEOS)  with  prognostic  microprocessors  to  sense,  detect,  consider,  prognose,  message  and 
perhaps  correct  problems.  The  paper  will  explain  how  miniature  electronic  technology  (E.T.)  will  use 
web  based  JAVA  technology  to  receive  rules  for  PHM  and  send  results  of  PHM  via  downlink  to  the 
Joint  Distributed  Information  System.  (JDIS)  The  paper  will  show  how  E.T.  is  embedded  in  the 
wiring,  cables  and  connectors  that  are  the  life  lines  of  the  electronic  systems,  and  how  E.T.  will  be 
fused  into  mechanical  structures  to  detect  aging  and  battle  damage.  Finally,  the  paper  will  describe  the 
cost  benefits  that  result  from  radically  changing  the  current  way  defense  systems  are  supported. 

1.0  The  Problem  with  Test  Equipment 

Test  equipment  and  test  software  program  sets  have  come  a  long  way  in  the  past  fifty  years.  In  the 
1950’s  test  procedures  often  were  done  with  a  voltmeter  and  eight  weeks  of  training  in  basic 
electronics.  The  transistor  changed  the  picture.  In  the  60’s  and  70 ’s  test  sets  were  developed  to 
check  the  combination  of  analog  signals  and  digital  “l’s  and  O’s”  used  in  avionics  and  other  systems. 
In  the  80 ’s  computer  programs  entered  the  picture,  adding  complexity.  “Can  Not  Duplicate”  and 
“Tests-OK”  now  represent  about  50%  of  test  results.  Maintenance  personnel  spend  about  ten  times 
longer  trying  to  “fix”  these  problems  and  often  introduce  a  fault  just  to  reduce  the  trouble.  “Cannot 
Duplicate”  (CND)  and  “Tests  OK”  (TOK)  situations  represent  about  50%  of  today’s  repair  results. 
CND  and  TOK  are  frustrating,  and  many  operators  just  ignore  the  fault  indications  and  hope  its 
another  “false  alarm”.  Test  equipment  from  the  days  of  TTL  logic  and  circuit  boards  just  cant  cope 
with  emerging  massively  parallel  architectures  used  in  defense  systems.  The  complexity  is  just  too 
great,  such  as  testing  the  stealth  characteristics  of  a  fighter  which  must  be  done  during  flight. 


History  has  shown  that  “false  alarms”  can  make  systems  appear  to  be  very  unreliable,  and  can  take 
several  maintenance  hours  per  flying  hour.  The  F-15  electronic  systems  have  a  average  “mean  time 
between  failure”  of  under  100  hours.  The  F-15  logs  about  25  maintenance  man  hours  per  flying  hour. 
Sortie  rates  are  affected  as  the  equipment  is  taken  offline  to  be  tested  and  repaired.  The  high  altitude, 
high  speed  missions  of  other  fighter  aircraft  like  the  F-16,  F-14,  and  F-18  aircraft  cause  similar 
headaches.  Other  aircraft  have  similar  situations,  albeit  of  a  lesser  degree,  as  their  roles  are  usually 
subsonic,  and  their  environment  for  use  is  more  benign.  However,  their  test  equipment  problems  are 
very  similar.  Developing  and  supporting  test  program  sets  is  a  big  business  dominated  by  a  select 
few  suppliers.  Test  sets  come  with  their  own  problems,  such  as  required  use  of  ADA  to  assure 
software  upgrades,  and  failure  rates  that  are  often  as  bad  as  the  equipment  being  tested.  The  problem 
is  getting  worse  as  software  begins  to  dominate  the  functionality  of  new  systems.  Testers  designed  to 
check  voltage  levels  are  not  suitable  for  testing  400mhz  computers  used  in  digital  signal  processors 
and  avionics  today. 

1.1  Cost  Aspects 

The  cost  of  maintenance  and  support  of  current  generation  weapon  systems  usually  exceeds  the 
delivered  cost.  Test  equipment  costs  are  sky  rocketing.  It’s  not  unusual  for  the  cost  of  the  ATE  to 
exceed  the  half  the  cost  of  the  product  it  is  built  to  test.  Spares,  parts,  TPS  and  ATE  are  very  big 
business.  The  US  Department  of  Defense  spends  about  $8  billion  on  test  related  hardware  each  year.1 
Solving  the  problem  of  external  test  equipment  is  not  a  simple  matter  of  spending  more  money. 

1.2  The  Added  Trouble  of  Commercial  Off  the  Shelf  (COTS)  Systems 

The  problem  of  cost  and  availability  is  not  limited  to  the  DoD.  Commercial  firms  and  businesses 
have  many  of  the  same  problems.  Commercial  producers  often  produce  only  a  few  years  of  spares. 
Automotive  firms  have  a  three  to  five  year  spares  policy.  Many  firms  find  that  it  is  cheaper  to  scrap 
a  failed  computer  or  system  than  to  try  to  find  replacement  parts.  The  DoD  hopes  to  replace 
expensive  custom  systems  with  systems  built  from  commercial  off  the  shelf  (COTS)  components. 
But,  most  commercial  off  the  shelf  (COTS)  components  are  not  designed  to  be  testable,  and  COTS 
products  are  usually  not  durable  enough  for  harsh  military  environments.  Also,  COTS  products  are 
constantly  upgraded  and  revised  to  add  new  technology.  New  systems  will  be  increasingly  complex. 

2.0  The  Joint  Strike  Fighter  (JSF) 

The  JSF  is  a  good  case  in  point.  Like  the  F-15,  the  JSF  is  a  multi-role  strike  fighter  aircraft.  In  the 
past,  this  meant  that  the  JSF  would  contain  about  one  hundred  analog  and  digital  “black  boxes” 
performing  dedicated  functions.  However,  the  JSF  will  be  mainly  “flying  software”  with  numerous 
distributed  computer  systems  that  will  share  and  participate  in  function.  The  JSF  will  be  a  “fly  by 
light”  supersonic  aircraft  with  electronic  “black  boxes”  running  complex  software.  Having  distributed 
processing  provides  redundancy  and  flexibility  which  mean  increased  survivability  and  inherent 
reliability.  But  inherent  reliability  only  lasts  until  the  first  failure.  Many  failures  will  be  software 
“glitches”  that  appear  to  be  failures  of  hardware.  Operational  availability  depends  on  the  repairability 
and  testability  of  the  hardware  and  software.  Unavailability  will  result  if  the  test  equipment  designed 
for  flying  hardware  is  unable  to  cope  with  the  new  design  architectures  that  replace  prior  generation 


1  Proceedings  of  the  DoD  Joint  Test  Conference,  Orlando,  FL,  1995 


net 


electronics  with  systems  based  on  software  signal  processing.  Untestability  at  the  flight  line  will 
result  in  sending  the  equipment  to  repair  depots  and  the  manufacturers,  inflating  the  pipeline  and  turn 
around  time. 


At  the  1996  testability  meeting  for  the  JSF,  test  system  and  test  software  manufacturers  said  that  the 
solution  to  having  better  testability  only  requires  more  time  and  more  money,  because  better  test  sets 
will  require  better  computer  programs.  But  this  means  that  the  test  modules  are  usually  delivered  long 
after  the  system  enters  service.  Test  equipment  also  fail,  in  two  ways.  They  often  fail  to  test  the 
equipment  they  were  designed  for.  And,  the  TPS/ ATE  components  fail,  requiring  test  sets  for 
repairing  the  test  sets.  The  Pentagon  budgets  for  TPS  and  ATE  represent  a  major  part  of  new  system 
acquisition  costs  and  will  rise  dramatically  if  something  is  not  done. 

3.0  Solutions 

Many  system  managers  wait  years  to  receive  test  program  sets  (TPS)  and  automatic  test  equipment 
(ATE)  that  simply  do  not  perform  as  required  because  the  test  set  programmers  and  developers  can’t 
cope  with  the  complexity  and  changes.  Faulty  equipment  gets  recycled  into  the  system  to  return 
again  with  great  consistency.  There  are  several  feasible  solutions  to  the  problem:  1)  allocate  much 
more  time  and  much  more  money  to  develop  test  program  sets  and  ATE  that  will  be  able  to  cope  with 
the  complexity,  or  2)  increase  the  amount  of  self  test  and  bit  within  the  electronic  systems.  The 
advantages  of  spending  more  money  on  test  equipment  and  test  programmers  are  entirely  in  the 
pockets  of  conventional  test  equipment  manufacturers  and  dedicated  repair  facilities. 

There  may  not  be  enough  time,  or  enough  money  to  produce  adequate  test  equipment  and  software. 
It  is  far  easier  to  take  advantage  of  the  built  in  processing  power  and  software  diagnostics  aboard  the 
system.  Real  time  diagnostics  and  tests  performed  aboard  the  system  makes  it  possible  to  use 
prognostic  health  management.  PHM  diagnostic  and  prognostic  procedures  will  provide  detection 
and  isolation  services  to  make  sure  that  only  true  hardware  failures  result  in  maintenance.  The  data 
generated  by  PHM  will  be  delivered  to  the  maintainers  along  with  recommended  procedures  to  assure 
a  quick  turn  around.  Figure  1  shows  the  principle  elements  of  autonomous  logistics  support. 
Incidents  aboard  mission  aircraft  cause  messages  to  flow  to  command  and  control  centers  of  forward 
logistics  support  centers.  Aircraft  can  be  serviced  at  any  facility  having  the  skills  and  parts  on  hand, 
or  the  resources  can  be  expressed  to  the  selected  support  center. 

3.1  JSF  Prognostic  Health  Management  (PHM)  Office 

The  JSF  program  for  PHM  is  managed  by  Dr.  William  Scheuren.  The  purpose  of  the  project  is  to 
dramatically  change  the  way  aircraft  and  systems  are  designed,  operated,  maintained  and  supported. 
The  JSF  PHM  office  is  promoting  research  and  development  of  pro-active,  built-in,  on-board 
diagnostic  and  prognostic  systems  that  will  increase  the  safety,  availability,  performance,  and 
affordability  through  innovations  including  use  of  advanced  “smart  systems”  using  sensor  technology. 
The  JSF  PHM  project  wants  real  timely  “Reactive  Supervision”  to  observe,  detect,  reason, 
understand  and  react  to  ongoing  events  during  missions,  during  maintenance,  and  throughout  the  life  of 
the  aircraft.  The  PHM  will  result  in  autonomous  logistics  support  achieved  through  watching  for 
symptoms,  detecting  problems,  isolating  faults,  and  performing  real  time  repair/restarts.  The  PHM 
system  will  report  to  cockpit  displays,  hand  held  maintenance  aids.  Data  links  will  transmit  health 
and  status  information  to  support  sites. 


3.2  Short  and  Long  Term  Goals 

The  long  term  DoD/JSF  goal  is  to  eliminate  ground  support  test  equipment  and  test  program  software 
wherever  possible  by  moving  test  and  diagnostics  on-board,  using  aircraft  computer  systems  to 
detect,  diagnose,  and  isolate  failures.  Another  goal  is  to  have  the  aircraft  systems  order  parts  and 
maintenance  during  the  course  of  the  mission  to  achieve  “autonomous  logistics  support”. 
Autonomous  logistics  would  be  like  breathing  is  to  humans,  eliminating  much  of  the  delays  that  choke 
and  limit  operational  availability.  The  DoD  would  like  to  eliminate  scheduled  maintenance  by  shifting 
to  “on  condition”  maintenance  as  needed.  The  JSF  program  wants  to  use  methods  similar  to  those 
used  by  commercial  aircraft  systems  developed  for  Lockheed  Martin,  Boeing  and  Airbus  Industries. 
New  commercial  aircraft  designs  like  use  on-board  diagnostic  systems  to  notify  ground  crews  of 
maintenance  needed  to  restore  airworthiness.  If  the  parts  are  in  a  city  other  than  the  destination,  the 
airline  has  time  to  get  the  parts  delivered  “just  in  time”  to  cut  the  time  otherwise  required  to  wait  for 
parts. 

4.0  Embedded  Self  Prognosis  and  Dynamic  Resource  Management 

Achieving  autonomous  supportability  will  require  innovations  that  use  fuzzy  logic  and  expert 
systems  to  “feel”  events,  detect  failures,  and  prognose  the  need  for  parts  and  maintenance  during 
flight.  The  self  prognosing  system  will  use  the  test  data  built  into  the  software  systems.  The  system 
will  determine  recurring  patterns  during  mission  operations  that  are  impossible  to  find  after  the 
system  has  returned  to  base.  The  diagnostic  software  will  assess  the  probable  root  causes  for  faults 
and  failures  relaying  the  information  to  ground  crews  along  with  work  instructions. 

In  1996,  DARPA  awarded  a  contract  to  explore  in-flight  embedded  self  prognosis  (ESP)  using  new 
software  and  sensor  techniques  to  identify  problems  and  select  the  maintenance  and  repair  methods. 
The  research  demonstrated  that  ESP  is  not  only  feasible,  but  demonstrated  using  ESP  handling 
“sledgehammer”  failures  in  distributed  computing  systems.  The  contract  identified  other  innovations 
such  as  moving  ESP  on  computers  in  “smart  wiring”  to  create  an  aircraft  neural  backbone.  MSI 
demonstrated  that  smart  wiring  can  be  used  to  detect,  isolate,  and  perform  other  reasoning  to  perform 
dynamic  resource  management  (DRM)  autonomously. 

5.0  Smart  Technology  for  Autonomous  Logistics  Support 

Smart  technologies  are  emerging  “just  in  time”  to  enable  autonomous  logistics  support.  “Smart” 
sensors  will  provide  the  data,  information  and  knowledge  required  for  “on  condition”  maintenance. 
The  use  of  intelligent  wiring  will  also  eliminate  many  of  the  problems  caused  by  frequent  technology 
upgrades.  Technology  upgrades  are  a  fact  of  life  caused  by  technology  advances  every  few  years. 
For  example,  many  JSF  electronic  systems  will  be  digital  signal  processors  (DSP)  that  replace  prior 
generation  radars  and  analog  systems  for  navigation  and  control.  Most  DSP  use  numerous  dedicated 
COTS  computer  processor  systems.  According  to  Moore’s  Law,  computing  technology  changes 
every  18  months.  (Many  claim  it  is  closer  to  nine  months  today.)  This  means  that  JSF  systems  will 
be  constantly  upgraded  with  new  technology  to  fend  off  obsolescence. 


6.0  Virtual  Prototype  Co-Design 

To  be  really  effective,  “smart  systems’’  for  PHM  need  to  be  designed  in,  with  “open  system” 
techniques  that  allow  room  for  planned  technology  upgrades.  The  Defense  Advanced  Research 
Project  Agency  (DARPA)  has  teamed  with  NASA  to  fund  development  of  hardware  and  software 
concurrent  design  using  virtual  prototyping.  Three  dimension  (3-D)  computer  aided  design  (CAD) 
programs  already  have  the  necessary  power  needed  to  create  a  virtual  hardware  prototype  of  the 
mechanical  design.  Chrysler  Corporation  has  been  advertising  how  they  virtually  prototype  new  car 
designs.  The  new  car  design  is  driven  over  virtual  highways  to  identify  areas  for  improvement  that 
improve  functionality,  reliability,  safety  and  maintainability.  The  Rapid  Prototyping  of  Application 
Specific  Signal  Processors  (RASSP)  project  started  in  1993  to  develop  computer  programs 
automatically  from  behavioral  specifications.  As  a  result,  co-design  is  being  used  to  identify  how  and 
where  to  place  sensors  that  will  provide  the  data  for  on-board  real  time  diagnostics,  and  to 
automatically  produce  the  diagnostic  and  prognostic  software  needed  to  eliminate  off  board  test 
program  sets. 

7.0  Neural  Circuits  and  Smart  Test  Modules 

To  be  cost  effective,  the  designers  of  reactive  supervision  must  dramatically  reduce  the  time  and  costs 
associated  with  writing  software  programs.  This  paper  presents  the  state  of  the  art  in  real  time 
reactive  supervision  using  neural  circuits  comprise  of  micro-computer  modules  equipped  with  micro¬ 
sensors.  Neural  circuits  are  not  neural  networks.  Rather,  neural  circuits  are  collaborating  computers 
that  work  together  to  optimize  reliability,  supportability,  maintainability  and  safety  as  part  of  the  on¬ 
board  computer  systems 

Smart  neural  sensor  test  modules  can  be  designed  autonomously  test  the  health  status  of  not  only 
electronic  systems,  but  also  the  mechanical  and  structural  systems.  Sensors  can  be  built  with 
microcontrollers  and  diverse  micro  machined  electro  mechanical  systems  (MEMS)  and  micro  optical 
sensors.  The  smart  sensor  will  process  the  data  using  rules  stored  in  a  knowledge  base.  When  the 
rules  indicate,  the  smart  sensors  take  appropriate  actions  in  the  form  of  messages  or  using  D/A 
converters  to  make  controlled  changes.  Smart  test  modules  connect  to  higher  level  smart  processors 
which  diagnose  and  prognose,  sending  condensed  information  to  ground  based  support. 
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Figure  1.  Smart  Sensor  Modules 


8.0  Reactive  Supervision 

Rule  bases  used  by  sensory  neural  circuit  modules  can  be  used  to  detect  when  system  elements  need 
inspection,  based  on  time  since  last  failure,  symptoms,  exposure  to  ultra  violet  rays,  temperature, 
vibration  and  corrosion.  Rules  can  be  established  enabling  autonomous  activity  to  discover  and  correct 
problems.  The  nature  of  the  reactive  measures  is  defined  in  “fuzzy  rules”  loaded  into  memory.  Smart 
sensors  can  take  reactive  supervisory  measures  defined  in  a  supervisory  program.  The  measures 
could  be  as  simple  as  generating  a  message,  or  as  complex  as  taking  collaborative  action  in  concert  with 
several  other  smart  sensor  devices  to  regain  control  of  situations. 

9.0  Rule  Based  Autonomous  Testability 

Autonomous  reactive  supervision  and  dynamic  resource  management  requires  data  inputs,  rules,  rule 
processing,  recognition  with  discrimination,  decision  processes  and  taking  actions.  The  rules  define 
the  sampling  rate  for  the  input  signals.  Rules  also  define  the  guidelines  for  reasoning  processes.  Java 
rules  define  the  nature  of  any  messages,  commands  or  other  actions  using  analog  drivers.  The  smart 
sensors  can  attempt  to  take  corrective  measures,  such  as  releasing  chemicals  to  stop  corrosion. 
Messages  can  be  used  to  notify  other  Smart  sensors  or  to  notify  maintenance  personnel  of  problems 
such  as  loose  connections  or  vibrations  that  cause  chafing.  If  wiring  is  damaged  due  to  fires  or 
collateral  damage,  the  smart  sensors  can  switch  to  a  better  wiring  configuration  using  cross  bar 
switches.  The  rules  used  to  detect  the  problems  also  provide  the  internet  URL  to  receive  the  report 
of  taking  preventive  actions.  If  desired,  the  receiving  URL  can  request  additional  information,  or 
request  another  configuration. 
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Figure  2.  Autonomous  Diagnostics  and  Test 


10.0  Autonomous  Logistics 

On  system  failure  isolation  and  verification  also  provides  “autonomous  logistics”  which  automatically 
order  the  parts  and  procedures  from  the  support  facilities  where  they  are  located.  Autonomous 
logistics  functions  react  immediately  to  gather  the  resources  dynamically,  unless  overridden  by  human 
commands.  Built  in  test  information  often  can  identify  the  root  cause  of  the  problem,  such  as  a  failure 
in  the  power  supply.  Economic  decisions  will  identify  the  best  way  to  restore  operation  of  the 
system,  and  operation  of  the  failed  units. 

11.0  “Smart”  Wiring 

Built  in  test  information  is  too  valuable  to  use  only  for  maintenance.  The  data  can  be  used  by  on¬ 
board  processors  to  facilitate  reassignment  of  assets  to  maintain  functionality  of  mission  critical 
systems.  The  wiring  system  that  carries  the  test  data  information  is  an  obvious  choice  for  siting  of 
PHM  sensors  and  dynamic  resource  managers.  By  embedding  computers  and  microcontrollers  in  the 
wiring,  the  electronics  and  software  will  be  tested  before,  during  use. 

ESP  in  smart  wiring  can  eliminate  much  of  the  ATE  and  TPS  that  would  otherwise  become  expensive 
baggage.  Demonstrations  of  the  concepts  were  held  in  late  May  1998.  The  JSF  PHM  program  office 
has  funded  research  projects  to  prove  that  smart  wiring  using  COTS  sensors  embedded  in  COTS 
electronics  and  wiring  is  cost  effective.  Demonstrations  are  scheduled  for  late  summer  and  early  fall 
of  1998.  On  aircraft  demonstrations  are  being  scheduled  for  the  summer  of  1999.  The  latter 
demonstrations  will  show  autonomous  reactive  supervision  by  on-board  diagnostic  and  test  systems 
embedded  in  the  wiring  system. 

The  advantages  of  using  “smart  wiring”  are  numerous: 

•  On-board  restoration  of  many  problems  by  rebooting,  cold  starts,  or  resets 

•  Accurate  run  time  detection,  diagnosis  and  isolation  with  on  board  computers 

•  Dramatic  reductions  in  NFF  and  RTOK 

•  Significant  reductions  in  maintenance 

•  Dramatic  reductions  in  life  cycle  support  costs 

•  Dramatic  reductions  in  costs  for  TPS  and  ATE 

•  Substantial  increases  in  operational  availability  and  supportability 

•  Dynamic  verification  and  validation  of  technology  upgrades. 

11.1  Applications  for  “Smart  Wiring” 

Wiring  carry  signals,  power  and  data  to  and  from  processes  attached  to  the  wires.  The  wiring  is  very 
much  like  the  veins  and  arteries  of  the  human  body.  Current  wiring  systems  are  passive.  Sensors  can 
be  added  to  the  data  network  that  are  analogous  to  neurons  that  provide  “feelings”.  The  wiring  is  an 
ideal  place  to  place  the  detection,  reasoning,  and  reacting  processors.  Inventing  a  new  generation  of 
“smart  wiring”  starts  with  destroying  most  of  the  rules  for  conventional  “dumb”  wiring.  Research  to 
develop  the  “first  generation  of  smart  wiring”  is  being  funded  by  the  JSF  PHM  office.  The  project  is 
getting  enthusiastic  support  from  DoD  agencies  who  bear  the  cost  and  frustration  associated  with  the 
current  generation  of  wiring  and  test  equipment. 


r- 


(o^ 


11.2  Advantages  and  Benefits  of  Smart  Wiring 

Currently,  most  wiring  is  simply  connections  of  wires  from  point  to  point.  Wiring  tends  to  work 
quite  well  until  it  is  subjected  to  environmental  and  electrical  forces  that  cause  minute  problems. 
Many  problems  take  ten  to  fifty  years  to  develop.  The  problems  are  usually  related  to  chemical 
deterioration  due  to  chemical  reactions.  When  wiring  begins  to  show  signs  of  wear  and  tear,  the 
problems  that  are  generated  can  be  very  troublesome.  In  fact,  most  maintenance  personnel  would 
rather  dig  ditches  than  attempt  to  isolate  problems  in  wiring  harnesses.  Current  wiring  systems  are 
simply  not  designed  for  trouble  shooting.  In  fact  they  seem  to  be  designed  to  confound  attempts  to 
isolate  problems. 

12.0  Real  Time  Logistics  Information  Systems 

In  its  long  term  vision,  the  DoD  wants  the  ground  support  system  and  aircraft  to  autonomously 
reconfigure  assets  in  order  to  complete  missions.  The  DoD  has  initiated  the  Joint  Distributed 
Information  System  (JDIS)  network  will  be  used  to  send  information  to  the  maintainers  on  exactly 
what  is  failed,  identifying  the  maintenance  procedure  and  parts  that  will  be  needed.  In  this  way  the 
support  staff  will  have  time  to  assemble  the  tools  and  parts  needed  to  make  quick  repairs.  On  arrival, 
the  maintainers  will  be  better  prepared  to  make  repairs  and  quickly  turn  the  system  to  fighting  status. 
In  peacetime,  the  failed  units  can  be  returned  to  the  manufacturer  for  warranty  support. 


13.0  Summary 

The  realities  of  shrinking  defense  budgets  require  massive  changes  in  the  way  systems  are  designed, 
tested,  maintained  and  supported.  As  a  result  of  new  initiatives,  testability,  availability,  and 
supportability  are  changing.  System  managers,  like  Dr.  William  Scheuren  of  the  Joint  Strike  Fighter 
PHM  office  are  making  significant  efforts  to  reduce  the  cost  and  problems  associated  with  test 
equipment,  maintenance,  and  logistics  support.  Defense,  automotive,  and  aerospace  companies  are 
designing  new  technology  to  bring  diagnostic  and  test  systems  on  board  to  enable  having  autonomous 
logistics  support,  higher  mission  availability,  and  dramatic  reductions  in  external  test  equipment. 


Using  autocoding  to  develop  test  software  will  cut  the  time  to  develop  test  software  by  several  orders 
of  magnitude. 
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This  paper  describes  the  application  of  statistical  testing  based  on  usage  models  (i.e.  using  a 
statistical  profile  to  select  and  generate  test  cases)  to  the  Improved  Mortar  Ballistics  Computer 
(IBMC),  a  next-generation  system  for  aiming  mortars  in  combat.  The  relationship  between  IMBC 
system  specifications,  usage  models,  and  FQT  scripts  are  described.  Suggestions  are  given  for 
tailoring  the  development  and  testing  processes  to  facilitate  the  successful,  cost-effective 
application  of  statistical  testing  to  FQT. 

Introduction 

In  statistical  testing  of  software,  a  software  usage  model  is  developed  to  characterize  a  population 
of  uses  of  the  software  (Figures  1  and  2).  The  structure  of  the  model  (states  and  arcs)  describes  the 
capabilities  of  the  software.  State  transition  probabilities  represent  a  particular  user  and  use.  The 
key  steps  in  developing  a  Markov  chain  usage  model  are  described  by  [7] .  The  application  of  these 
ideas  to  the  U.S.  Army  TACOM’s  IMBC  project  are  described  in  later  sections  of  this  paper. 

Because  it  is  impossible  to  exhaustively  test  non-trivial  software,  it  is  important  to  determine  the 
most  efficient  use  of  the  test  budget  to  satisfy  the  test  objectives  of  the  software  life  cycle.  Mills 
[3]  pointed  out  that  testing  with  selected  test  cases  can  provide  nothing  but  anecdotal  evidence; 
statistical  testing  is  needed  to  scientifically  certify  the  reliability  of  software.  The  Testing  Maturity 
Model  [1]  describes  behavioral  characteristics  of  organizations  at  five  testing  maturity  model 
levels.  In  the  model  they  state  that  at  the  highest  testing  maturity  level,  “usage  modeling  is  used  to 
perform  statistical  testing”. 

Statistical  testing  of  software  allows:  modeling  and  quantitative  analysis  of  software  specifications, 
quantitative  test  planning  and  evaluation  of  test  plans,  and  automatic  generation  of  a  statistically 
correct  sample  of  test  cases.  Test  management  decisions  can  be  based  on  scientific  data  that  is 
computed  before  and  during  the  test.  The  benefits  of  usage  model-based  statistical  testing  to 
support  test  planning,  test  generation,  test  automation,  and  software  certification  have  been 
demonstrated  in  numerous  industry  and  government  software  development  projects  and  have  been 
reported  in  various  forums.  For  example:  Texas  Instruments  described  the  benefits  of  applying 
statistical  quality  control  principles  to  test  embedded  software  [4],  and  the  IBM  laboratory  in 
Tucson  reported  that  statistical  testing  of  software  based  on  a  usage  model  for  mass  storage  device 
driver  software  “dramatically  increases  measurement  opportunities  both  before  and  during  the 
testing  process”  [9]. 

Despite  the  documented  advantages  of  statistical  testing  based  on  usage  models,  many 
organizations  are  reluctant  to  consider  a  shift  from  traditional  testing  to  statistical  testing.  We 
discuss  one  example  of  successful  technology  transfer  to  statistical  testing  at  the  U.S.  Army 
TACOM. 


Application  of  Statistical  Testing  to  the  IMBC 

The  Improved  Mortar  Ballistics  Computer  (IMBC),  a  next-generation  system  for  aiming  mortars  in 
combat,  consists  of  approximately  90,300  lines  of  Ada  code  developed  using  an  incremental  life 
cycle.  The  IMBC  certification  team  was  initially  very  reluctant  to  rely  on  statistical  methods  and  a 
usage  model-based  sample  to  drive  IMBC  testing.  There  were  a  variety  of  reasons  for  their 
reluctance:  it  was  a  new  certification  team;  the  development  project  was  using  a  new  process  [6]; 
the  requirements  continued  to  evolve  during  the  specification  and  development  work;  and  there 
were  typical  budget  and  schedule  pressures.  However,  the  project’s  management  was  committed  to 
the  application  of  statistical  testing  methods  for  this  project,  and,  after  some  discussion,  the 
certification  team  agreed  to  expend  a  significant  portion  of  the  IMBC  testing  effort  on  statistical 
testing. 

Formal  training  in  statistical  testing  was  provided  to  the  certification  team  members  at  the 
beginning  of  the  IMBC  project.  During  increment  5,  some  one-on-one  training  was  provided  for 
new  team  members.  Because  there  was  a  100%  turnover  in  the  certification  team  between 
increment  3  and  increment  5,  another  formal  training  course  in  statistical  testing  was  provided  at 
the  beginning  of  the  increment  6  usage  modeling  effort.  Coaching  was  provided  on  an  “as  needed” 
basis  throughout  the  project.  The  CASE  tool  product,  toolSET_Certify  from  Software  Engineering 
Technology,  Inc.,  was  used  to  support  usage  modeling,  test  planning,  test  case  generation,  and 
statistical  analysis  of  test  results. 

Some  traditional  testing  and  some  statistical  testing  was  performed  on  each  IMBC  increment. 
Statistical  methods  were  used  to  predict  a  field  reliability  of  0.93  for  the  system  as  it  existed  at  the 
end  of  increment  6. 

IMBC  Statistical  Testing  Activities  and  Issues 

A  defined  process,  training,  coaching,  and  tool  support  were  key  contributors  to  the  success  of  the 
IMBC  project's  adoption  of  statistical  testing  methods.  Despite  the  turnover  and  associated 
learning  curves,  the  certification  team  successfully  applied  some  amount  of  statistical  testing  and 
some  amount  of  traditional  testing  in  each  increment.  The  following  gives  brief  highlights  of  some 
of  the  key  activities  and  issues  addressed  during  IMBC  statistical  testing. 

Identify  the  test  objectives  and  constraints 

Because  of  constraints  of  evolving  requirements  and  limited  testing  budget  and  schedule,  a  decision 
was  made  early  in  the  project  that  it  was  not  necessary  to  fully  certify  each  increment.  Each  IMBC 
increment  had  a  test  objective  to  demonstrate  that  the  development  process  for  that  increment  was 
in  control.  Statistical  methods  were  used  in  all  increments  for  test  planning  and  to  generate  test 
cases  from  a  usage  population  defined  by  a  usage  model.  Increments  5  and  6  were  by  far  the  most 
complex  and  included  major  parts  of  the  functionality  of  the  IMBC.  Thus,  more  extensive  testing 
was  performed  on  the  full  system  in  increment  6.  Statistical  methods  were  used  to  predict  the  field 
reliability  for  IMBC  as  it  existed  at  the  end  of  increment  6.  FQT  was  performed  using  traditional 
methods  after  increment  7. 
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Determine  test  environment  and  automation  issues 


Because  the  target  platform  for  IMBC  was  unknown,  testing  was  performed  on  a  single-user  DOS- 
based  machine.  Because  testing  was  constrained  to  a  DOS  platform,  test  case  execution  and 
evaluation  of  correctness  was  done  manually.  Windows-based  test  capture  and  replay  tools  could 
have  helped  automate  the  IMBC  testing  process.  Other  projects  [2,4,5]  have  reported  success  in 
automating  execution  and  evaluation  of  statistical  tests.  For  IMBC,  if  automated  test  execution  and 
evaluation  were  available,  the  resulting  reduction  in  the  time  to  run  a  test  script  could  have 
supported  (within  the  same  test  budget)  statistical  testing  of  more  complete  usage  scenarios  and 
more  atypical  scenarios. 

Define  test  boundaries 

The  entire  system  was  tested  at  the  end  of  Increments  3,  6,  and  7.  New  screens  and  modified 
screens  were  tested  at  the  end  of  Increments  4  and  5.  For  software  supplied  and  previously 
acceptance  tested  by  another  U.S.  Army  organization,  only  the  interfaces  were  tested. 

Define  user,  and  use 

Because  the  IMBC  was  designed  with  the  capability  of  providing  continual  battlefield  support, 
“invoke  a  use”  and  “terminate  a  use”  in  the  IMBC  did  not  have  the  same  meanings  as  “invoke  the 
software”  and  “terminate  the  software”.  Thus,  some  discussion  was  required  before  the  team 
reached  a  consensus  on  the  definition  of  use  from  which  to  develop  usage  models.  For  the  purpose 
of  statistical  testing,  the  “user”  of  the  IMBC  was  defined  as  a  soldier  in  the  field  (either  in  training 
or  in  battle).  A  “single  use”  of  the  IMBC  was  defined  as  “performing  one  or  more  missions”. 
“Invoke  a  use”  was  defined  as  initializing  data  for  a  mission  (a  new  use  may  or  may  not  build  on 
data  from  previous  uses).  “Terminate  a  use”  was  defined  as  termination  of  a  mission  (with  or 
without  save)  or  completing  a  mission  (may  or  may  not  have  computed  values  for  the  mission). 

Determine  appropriate  usage  model  strata 

Possible  usage  strata  were:  fire  solution  versus  non-fire  solution,  and  type  of  mission  (grid,  shift, 
polar,  or  laser) 

Develop  and  document  usage  model  structure  for  each  model 

Despite  the  discussions  to  define  “use”  of  the  IMBC,  because  the  certification  team  was 
inexperienced  in  usage  modeling,  it  was  difficult  for  them  to  consider  the  usage  model  structure 
from  multiple  views.  However,  given  the  complexity  of  the  IMBC  specification,  multiple  views 
were  required  to  meet  the  testing  objectives. 

The  IMBC  GUI  specification  was  screen-based.  A  usage  model  from  the  viewpoint  of  screen 
navigation  was  excellent  for  describing  “what  can  we  do  at  each  screen”  and  was  excellent  for 
verifying  completeness  and  consistency  of  the  specification.  Because  a  very  long  stimulus  history 


is  required  to  define  the  probability  of  a  particular  transition,  a  screen-based  usage  model  was  less 
appropriate  for  describing  usage  scenarios  that  would  be  typical  in  the  battlefield. 

Typical  IMBC  system  usage  is  highly  modal  because  specific  types  of  missions  have  very  distinct 
characteristics,  however,  the  IMBC  software  was  not  highly  modal.  It  was  designed  to  be  very 
flexible  and  allowed  many  transitions  between  modes.  This  flexible  design  provided  maximum 
flexibility  to  the  soldier  in  use  of  the  system  and  improved  maintainability  of  the  software.  As  is 
often  the  case,  design  flexibility  brought  an  additional  testing  cost.  One  testing  issue  was  caused  by 
the  fact  that,  like  most  non-modal  software,  the  number  of  possible  paths  through  the  IBMC 
software  was  veiy  large.  A  well-defined  specification  and  development  process  including 
verification  of  the  software  prior  to  test  mitigated  some  of  the  risk  resulting  from  insufficient 
budget  to  test  the  possible  paths.  Another  testing  issue  for  IMBC  was  that  “typical  use”  couldn't  be 
accurately  described  with  fixed  probability  distributions  if  the  usage  model  was  developed  with 
each  state  representing  a  unique  screen.  A  variety  of  usage  modeling  techniques  were  used  to 
control  the  complexity  of  the  usage  modeling  activity  and  to  help  the  testing  team  deal  with  this 
issue.  These  techniques  included  the  use  of  component  modeling,  state  and  arc  abstraction, 
stratification  of  input  data,  and  scenario-based  usage  stratification. 

Determine  transition  probabilities  for  each  model 

Some  transition  probabilities  were  assigned  based  on  testers’  “best  guess”  from  conversations  with 
users  of  the  predecessor  system  to  IMBC.  The  remaining  transition  probabilities  were  assigned 
according  to  policies  developed  based  on  objectives  and  constraints  of  the  testing  for  each 
increment  using  some  of  the  techniques  described  in  [8]. 

Process  Benefits  of  IMBC  Usage  Modeling 

The  IMBC  team  realized  the  benefits  of  usage  modeling  as  a  specification  activity  very  quickly. 
Because  usage  models  were  developed  from  the  functional  specification  for  the  software,  the  usage 
modeling  process  provided  valuable  insights  into  the  completeness  and  consistency  of  the 
functional  specification  for  each  increment  of  the  IMBC  project.  This  facilitated  identification  of 
specification  problems  before  coding  was  completed. 

The  usage  modeling  process  yielded  artifacts  that  provided  clear  documentation  of  the  certification 
team's  interpretation  of  the  system  functionality.  This  greatly  improved  communication  between 
the  certification  team  and  the  specification  and  development  teams. 

By  careful  planning  and  the  use  of  systems  of  component  models,  the  certification  team  was  able  to 
realize  significant  reuse  of  usage  models  in  each  subsequent  increment.  This  provided  significant 
savings  in  model  development  and  verification  effort  and  made  it  easier  for  the  certification  team  to 
tailor  the  model  for  each  increment  to  meet  the  test  objectives  for  that  increment. 

IMBC  Formal  Qualification  Tests  and  Their  Relationship  to  Statistical  Tests 


The  objective  of  the  IMBC  Formal  Qualification  Tests  (FQT)  was  to  demonstrate  that  the  IMBC 
correctly  performed  all  the  functionality  included  in  the  System  Requirements  Specification  (SRS). 
A  different  team  than  the  IMBC  certification  team  performed  FQT. 

The  IMBC  SRS  included  natural  language  descriptions  of  requirements  from  the  operational 
perspective.  Specific  data  values  to  be  tested  were  included  in  the  SRS.  After  a  small  number  of 
statistical  tests  were  run  on  the  full  IMBC  system  after  increment  7,  FQT  was  performed  using 
traditional  methods  to  evaluate  conformance  of  the  IMBC  software  to  the  SRS.  Although  many 
more  test  sequences  were  run  during  FQT  than  during  the  statistical  test  of  the  system  after 
increment  7,  neither  the  statistical  tests  nor  the  FQT  were  extensive  enough  to  be  described  as  a 
statistically  typical  sample  of  any  defined  population  of  IMBC  use. 

After  FQT  was  completed,  FQT  test  scripts  and  test  results  were  analyzed  to  determine  the 
relationship  between  the  FQT  scripts  and  the  usage  models  developed  to  drive  the  testing  of  each 
increment.  The  basic  difference  between  the  FQT  test  scripts  and  the  usage  models  can  best  be 
described  by  the  test  objectives.  The  usage  model  structures  were  developed  to  exercise  the 
functionality  of  the  screens.  Thus  the  granularity  of  the  usage  models  tended  to  be  close  to 
uniform,  and  usage  model  scripts  led  the  tester  through  each  screen,  giving  indications  for  type  of 
data  to  be  entered  but  not  specific  values.  For  example  two  arcs  in  the  usage  model  were  “select 
existing  Reg  Pt”  and  “Press  use  all  of  valid  data”.  The  work  to  define  the  specific  data  to  be 
entered  during  testing  was  done  by  the  testing  team  outside  the  usage  model.  (This  method  of 
selecting  test  data  after  the  test  scripts  was  generated  was  the  preference  of  the  testing  team.  More 
detailed  test  planning  based  on  the  usage  models  could  have  yielded  a  more  detailed  model  that 
included  multiple  arcs  between  states  with  stratified  data  values  specified  on  the  arcs.) 

In  contrast  to  the  usage  model  scripts,  the  FQT  scripts  were  developed  to  test  specific  data  values 
for  specific  missions,  specific  weapons,  and  specific  conditions.  In  general,  the  FQT  scripts  get  the 
tester  quickly  to  a  specific  screen,  then  give  very  specific  instructions  to  the  tester  to  loop  through  a 
series  of  screens  multiple  times,  checking  various  specific  combinations  of  data  values. 

For  example,  Figure  2  gives  a  high-level  usage  model  structure  that  could  be  used  to  describe  a 
subset  of  the  IMBC  software.  In  addition  to  the  transition  lines  drawn  in  the  figure,  there  are  also 
possible  transitions  from  every  state  back  to  “Main  Menu”  and  from  every  state  to  “Terminate 
Use”.  An  FQT  script  to  exercise  Fire  Data  with  three  sets  of  data  might  be  of  the  form  (where  “0” 
represents  the  details  of  data  entry  for  that  screen):“Use  Not  Invoked,  Main  Menu...  Fire  Mission... 
Current  Mission...  Fire  Data...  Current  Mission...  Fire  Data...  Current  Mission...  Fire  Data... 
Safety  Data... 0  Use  Terminated” 

In  contrast,  a  series  of  scripts  generated  from  a  usage  model  with  a  structure  such  as  that  indicated 
in  Figure  2  would  most  likely  not  be  similar  to  the  script  above.  It  is  likely  that  sequences 
generated  automatically  from  the  usage  model  described  above  would  require  navigation  through 
other  parts  of  the  usage  model  before  3  fire  data  scenarios  were  completed.  For  example, 
depending  on  the  assignment  of  transition  probabilities,  a  random  walk  through  the  usage  model 
might  yield  a  sequence  such  as:  “Use  not  Invoked  Main  Menu...  Fire  Mission...  Current  Mission... 
Use  Terminated,  Use  not  Invoked  Main  Menu...  Met...  Use  Terminated,  Use  not  Invoked  Main 
Menu...  Met . ” 


A  comparison  of  the  IMBC  FQT  scripts  with  the  full  IMBC  usage  model  yielded  the  following 
information: 

Each  of  the  FQT  scripts  could  have  been  generated  from  the  usage  models.  With  careful  planning, 
cost-effective  statistical  testing  could  have  been  used  for  all  the  FQT  tests. 

Because  the  FQT  scripts  and  the  usage  models  were  developed  by  different  teams,  one  relying 
predominately  on  the  SRS  and  one  relying  predominately  on  the  specifications,  the  names  of  the 
screens  and  data  values  differ  between  the  FQT  and  model  scripts.  This  makes  it  difficult  to 
automatically  map  FQT  scripts  onto  the  usage  model  for  comparison  of  the  Markov  chain  statistics. 

The  FQT  approach  minimizes  the  number  of  keystrokes  required  to  test  specific  functions  with 
specific  data  values. 

Making  an  assertion  about  operational  use  based  on  FQT  results  would  require  that  one  make  some 
assumption  about  whether  multiple  sequential  executions  of  a  particular  series  of  screens  will 
succeed  or  fail  in  the  same  way  as  multiple  execution  of  the  series  of  screens  when  interspersed 
with  other  uses  of  the  software.  This  assumption  may  not  be  valid.  The  IMBC  software 
accumulates  state  differently  depending  on  the  history  of  use  of  the  software. 

The  FQT  scripts  tended  to  concentrate  on  one  small  subset  of  screens  to  demonstrate  that  a 
particular  system  feature  executed  correctly  with  multiple  sets  of  data  values.  Less  testing  was 
done  to  ensure  that  the  feature  executed  correctly  after  a  significant  number  of  missions  had  been 
run  (and  a  significant  amount  of  potential  state  accumulation.) 


The  FQT  scripts  tended  to  do  less  testing  of  the  “cancel”  arcs  and  other  unlikely  paths. 

Process  Tailoring  to  Facilitate  Cost-Effective  Testing 

Many  of  the  perceived  barriers  to  application  of  statistical  testing  are  in  fact  barriers  to  a  rigorous 
testing  program  of  any  method.  The  IMBC  testing  experience  demonstrated  that  statistical  testing 
provides  a  well-defined  process  for  test  planning,  test  case  generation,  test  execution,  and  analysis. 
The  artifacts  generated  from  statistical  testing  provided  excellent  documentation  for  the  testing 
program  and  decision  making  process.  With  a  small  amount  of  training  and  support,  even 
inexperienced  testers  quickly  became  effective,  productive  testers. 

Analysis  of  the  project  yields  some  suggestions  for  process  tailoring  to  facilitate  an  organization’s 
transition  from  traditional  testing  to  statistical  testing.  The  key  to  successful  application  of 
statistical  testing  is  a  defined  process  with  careful  tailoring  to  address  local  issues.  This  was 
demonstrated  in  the  IMBC  project  and  other  projects  [6,2].  Particular  care  must  be  given  to  the 
following  issues: 

The  management  objectives  and  constraints  of  the  certification  program  must  be  documented  and 
well  understood  by  management,  the  certification  team,  and  the  development  team.  These 


objectives  and  constraints  must  be  used  to  define  the  scope  of  the  testing  program  as  well  as  to 
allocate  testing  resources. 

Certification  team  members  must  share  responsibility  with  the  requirements,  specification,  and 
development  teams  for  review  of  the  specification  and  communication  about  any  and  all 
assumptions. 

There  must  be  a  specification  of  sufficient  detail  to  provide  a  clear  definition  of  correct  execution 
of  the  software. 

There  must  be  traceability  (including  a  common  language)  between  the  requirements  and  the 
specification,  and  the  testing  team  must  clearly  understand  both  the  functional  views  and  the  usage 
scenario  views  of  the  software. 

Potential  reuse  of  usage  models  across  increments  or  versions  of  the  software  and  application  of 
statistical  testing  throughout  the  life  cycle  (including  FQT)  must  be  considered  during  the  test¬ 
planning  phase. 

Multiple  views  of  the  software  must  be  modeled  and  analyzed  to  determine  an  optimal  test  plan  for 
each  phase  of  the  software  life  cycle. 
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Figure  2.  High-level  Usage  Model  Structure 
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